Програма установки захищених мережевих з`єднань з використанням протоколу ISAKMP

Введення

Internet останнім часом став популярною, недорогий базової інфраструктурою. Універсальний доступ до нього змусила багато компаній розглянути можливість створення віртуальної захищеної мережі (Virtual Private Network VPN) на основі глобальної мережі Internet (який, по суті, являє собою сукупність мереж). Переваги VPN полягає у використанні базової інфраструктури Internet та для комунікацій усередині компанії (включаючи її різні відділення) і для зв'язку між компаніями, причому захищеність даних сполук залишається такою ж, як і в локальних корпоративних мережах.

Корпоративна мережа характеризується тим, що всі її управління знаходиться в руках її власників, дані, передані по ній, проходять тільки через вузли входять в цю мережу і взаємодія із зовнішнім світом виражається в невеликому обсязі переданих даних (іноді і повному відсутність). За таких самодостатніх умовах мережу можна було зробити захищеною. VPN переводить корпоративну мережу на базис Internet. При цьому, однак, виникає ряд істотних труднощів. Жоден з вузлів не може керувати Internet-му. Дані з різних джерел передаються за допомогою загальної інфраструктури. Також, завдяки розвитку електронної комерції та бурхливому зростанню мережевих технологій, значно зріс обсяг даних переданих між компаніями. Виходячи з усіх перерахованих вище особливостей, можна зробити висновок, що структура VPN істотно відрізняється від старої традиційної корпоративної мережі.

Координаційною радою IETF (Internet Engineering Task Force) був розроблений і запропонований набір протоколів захисту мережевих з'єднань [3]. IPSec протоколи забезпечують цілісність і конфіденційність інформації, а також управління ключовою інформацією та політикою захищених з'єднань. Відмінною особливістю IPSec від більш ранніх подібних протоколів полягає в захисті всього шляху прямування переданих даних (а не фрагмента, як це було раніше).

Для захисту трафіку було запропоновано два протоколи AH (Authentication Header) і ESP (Encapsulating Security Payload). Протокол AH (Authentication Header) полягає в підрахунку і перевірки значення хеш-функції з ключем від переданих даних. Протокол AH забезпечує цілісність і автентичність даних і захищає від атак, заснованих на переповторах пакетів (replay attack). В основі ESP протоколу лежить шифрування і розшифрування даних, і він забезпечує ті ж функції, що і AH, і додатково конфіденційність переданої інформації.

Ці дві вказані вище особливості призвели до виникнення проблеми управління ключової інформації і політик (параметрів) з'єднань. Найпростішим рішенням є ручне конфігурування сполук, при якому параметри і секретні ключі жорстко прописуються під час запуску системи. До єдиного гідності можна віднести відносну простоту даного методу. Найбільшим же недоліком даного методу можна вважати відсутність «масштабованості». Це означає, що для встановлення секретного з'єднання ручним конфігуруванням обидві сторони повинні домовитися про ключ, що використовується для захисту трафіку та про параметри його використання (вибір протоколу, алгоритму і т.п.). Якщо мова йде про систему, що складається з невеликої кількості користувачів, то ніяких проблем не виникає. Коли ж кількість користувачів становить кілька тисяч (десятків, сотень ...) процедура конфігурування стає практично нездійсненним завданням. Іншим недоліком ручного конфігурування можна вважати відсутність простого механізму зміни використовуваного ключового матеріалу. Тобто ключ шифрування буде використовуватися занадто довго (для занадто великого обсягу даних), що знижує захищеність переданих даних.

Іншим способом конфігурування сполук є використання спеціальних «key management» протоколів. Одним з таких протоколів з'явився ISAKMP. Даний протокол був також запропонований координаційною радою IETF. Протокол працює незалежно від модуля здійснює захист переданих даних. Результатом роботи протоколу є домовлені між двома партнерами параметри захищеного з'єднання (включає в себе набір використовуваних протоколів захисту даних, алгоритми, використовувані в цих протоколах, параметри алгоритмів) і ключова інформація, для використовуваних алгоритмів. Отримана інформація є вихідними даними для протоколу і повинна бути передана модулю захисту переданих даних.

Протокол ISAKMP повністю вирішує проблему «масштабованості». Ключовий матеріал вираховується на основі даних, переданих в процесі аутентифікації партнера і договору параметрів з'єднання. При розрахунку також використовується випадкові величини, генерящіеся кожної зі сторін для даного з'єднання, що забезпечує різний ключовою матеріал при двох спробах встановлення з'єднання між одними і тими ж партнерами. Дана властивість також дозволяє не описувати правило секретного з'єднання для кожного з абонентів, а об'єднувати їх по якій-небудь ознакою (підмережа, діапазон IP адрес, певний протокол і т.д.) і описати для них одне правило створення секретного з'єднання.

Протокол також вирішує і проблему часу життя ключової інформації. Час життя ключової інформації (в секундах і кілобайтах) є одним з параметрів домовляємося з'єднання. Таким чином, легко регулюється час використання ключа або обсяг даних, який можна цим ключем шифрувати, і з'являється механізм, що дозволяє запустити створення нового з'єднання при закінченні часу життя ключової інформації.

Аналіз методів реалізації системи захисту мережевих з'єднань

Як тільки мережеві технології стали використовуватися корпораціями для передачі конфіденційної інформації, виникла проблема захисту цієї переданої інформації.

Найпершим методом захисту мережевих з'єднань створення локальних корпоративних мереж. Їх відмітною особливістю був повний контроль над усіма елементами, що входять в цю мережу, усіма вузлами, через які проходила інформація. Локальна корпоративна мережа була самодостатньою і часто замкнута в собі. Вона або зовсім не мала виходу у зовнішній світ, чи виходить трафік ретельно фільтрували. Пов'язані з цим тимчасові затримки нікого не хвилювали, тому що цей трафік був дуже не значним. При такому невеликому, повністю контрольованому обладнанні, корпоративні мережі вважалися достатньо захищеними.

Але сьогоднішні корпоративні мережі розвиваються згідно з новими моделями компаній: корпоративна мережа сьогодні це набір фізично розділених локальних мереж, сполучених за допомогою загальнодоступної мережі Internet, а взаємозв'язок між компаніями сьогодні життєво необхідна. Ця нова модель компанії винесла на загальний огляд передані дані, чого не робила стара корпоративна мережа. Розробники та користувачі VPN повинні усвідомлювати небезпеку цієї відкритості і захищатися від неї. Добре продумана політика захисту VPN дозволить компанії організувати з'єднання між локальними мережами і між компаніями з такою ж гарантією, як і в старих традиційних корпоративних мережах.

Для захисту трафіку всередині VPN були потрібні спеціальні протоколи передачі даних і протоколи для отримання параметрів з'єднання і ключової інформації. На даний момент до протоколів першого типу відносяться AH (Authentication Header) і ESP (Encapsulating Security Payload). AH передає дані й певну підпис за цими даними, що забезпечує їх цілісність і справжність. ESP передає зашифровані дані, що забезпечує додатково конфіденційність даних.

До протоколів, що забезпечує AH і ESP необхідними параметрами і ключовою інформацією, належить протокол ISAKMP. Він і буде докладніше розглянуто далі в цій главі.

Структура протоколу ISAKMP

У цьому розділі буде розглянуто, як ISAKMP протокол домовляється про параметри і обмінюється ключами між двома системами, які хочуть створити секретне з'єднання [4].

Для того щоб розглянути всі на конкретному прикладі приймемо, що метод аутентифікації - заздалегідь відомий секретний ключ (preshared key).

Всі пакети, якими обмінюються партнери в процесі встановлення з'єднання, починаються з ISAKMP заголовка. Він містить деяку ідентифікаційну інформацію (Initiator Cookie, Responder Cookie і Message ID), тип обміну, прапори, номер версії та довжину всього пакету.

Основне тіло пакета складається з payload-ів. Payload - обсяг інформації, що несе певне смислове навантаження. Надалі цей елемент будемо називати «компонентом».

Фаза 1 (Main Mode)

Метою першої фази є створення секретного з'єднання, під захистом якого будуть проходити всі наступні обміни [5]. Фаза складається з 6 обмінів - 3 з боку ініціатора і 3 з боку відповідача (Мал. 1).

Рис. 1. Структура фази 1 (Main Mode)

У пакеті 1 ініціатор посилає SA payload, компонент, який містить всі пропоновані варіанти параметрів з'єднання. Його структура представлена ​​на малюнку 2.

Рис. 2. Структура SA payload

SA payload містить усередині себе список Proposal payload-ів, кожен з яких представляє собою окремий протокол. Proposal payload-и можуть об'єднуватися в групи по «І» і по «АБО». Це здійснюється за допомогою номерів даних компонент - однакові номери означають об'єднання по «І», а різні за АБО. У свою чергу Proposal payload містить список Transform payload-ів, які представляють алгоритми для даного протоколу. Об'єднані вони можуть бути тільки по «АБО». Transform payload містить список атрибутів, які конкретизують даний алгоритм (довжина ключа) і містять інші параметри з'єднання. Атрибути не можуть вибиратися, або приймається весь список атрибутів або все відкидає.

Таким чином, ініціатор посилає відповідачеві на вибір список списків протоколів і для кожного протоколу на вибір список алгоритмів. З усього цього відповідач вибирає список протоколів, причому для кожного протоколу може бути вибраний тільки один алгоритм і набір атрибутів для даного алгоритму не може змінюватися (ні додавання / видалення, ні зміни), тобто алгоритм або приймається з усім списком атрибутів, або відкидається. Обрана інформація оформляється також в SA payload, і відправляється ініціатору другим пакетом.

Підсумком перших двох пакетів, або першого обміну, ставати домовленість щодо параметрів з'єднання.

У пакетах 3 і 4 передаються KE payload і Nonce payload. У КЕ payload ініціатор і відповідач обмінюються своїми відкритими ключами для алгоритму Diffie - Hellman. Вони потрібні на наступних етапах для розрахунку загального ключа. Nonce payload містить випадкову послідовність будь-якого розміру, які також будуть брати участь при розрахунку ключової інформації.

Після цього обміну можна почати розрахунок ключової інформації. На основі чужого відкритого і свого секретного ключів розраховується загальний ключ (g ^ xy) за алгоритмом Diffie - Hellman. Потім проводиться розрахунок деяких службових констант.

SKEYID = PRF (Preshared Key, Ni | Nr)

де Preshared Key - заздалегідь відомий секретний ключ.

SKEYID _ d = PRF (SKEYID, g ^ xy | CKY - I | CKY - R | 0)

SKEYID _ a = PRF (SKEYID, SKEYID _ d | g ^ xy | CookieI | CookieR | 1)

SKEYID _ e = PRF (SKEYID, SKEYID _ a | g ^ xy | CookieI | CookieR | 2)

З формул видно, що в розрахунку всіх констант (а, отже, і в усіх подальших розрахунках) бере участь відомий тільки обменивающимся сторонам секретний ключ (Preshared Key), що забезпечує аутентифікацію сторін, тому що ніхто інший не зможе правильно рас читати ці константи.

З SKEYID _ e ми отримуємо ключову інформацію. Решта константи будуть використані при подальших розрахунках.

У пакетах 5 і 6 партнери обмінюються інформацією, яка їх ідентифікує (IDii і IDir) та інформацією, яка їх аутентифікує (HASH _ I, HASH _ R). Ідентифікаційна інформація передається за допомогою Identification payload, де вказується тип ідентифікаційної інформації (IP адреса, ім'я користувача, SubNet тощо) та власне значення.

Аутентифікаційні інформація передається через Hash payload. Його вміст розраховується за такими формулами (для ініціатора і відповідача відповідно):

HASH _ I = PRF (SKEYID, g ^ xi | g ^ xr | CookieI | CookieR | SA i | IDii)

HASH _ R = PRF (SKEYID, g ^ xr | g ^ xi | CookieR | CookieI | SA i | IDir)

Останній обмін (пакет 5 і 6) вже передається захищеним за допомогою домовлених на першому етапі алгоритмів і розрахованої після другого пакету ключовою інформацією.

Фаза 1 (Aggressive Mode)

Aggressive Mode виконує ті ж функції, що й Main Mode, але укладається всього в три пакети [5]. Таке спрощення, однак, призводить до того, що він більш схильний до атак, ніж Main Mode. На малюнку 3 представлена ​​структура Aggressive Mode.

У пакеті 1 ініціатор посилає відразу SA payload з пропозицією параметрів з'єднання, KE payload зі своїм відкритим ключем, Nonce payload з випадковою інформацією та ідентифікує себе з допомогою Identification payload.

Відразу видно недоліки даного режиму. У SA payload-е не може бути запропоновано більше однієї групи параметрів для алгоритму Diffie - Hellman-а тому що відразу ж надсилається відкритий ключ, а її розмір прямо залежить від цих параметрів. У даному режимі, на відміну від Main Mode, ідентифікаційна інформація надсилається у відкритому вигляді.

Відповідач, отримавши пакет 1, вже має достатньо інформації для розрахунку робочих констант і своєї аутентификационной інформації. Тому в пакет 2 складається з тих же частин, що і пакет 1 (з відповідним наповненням) і додається Hash payload, що містить інформацію, аутентифицирующей відповідача. Пакет ще не може бути зашифрований (оскільки ініціатор не знає обраного алгоритму і у нього немає ключів), але можна вже провести ключової інформації, яка буде використана в майбутньому.

Рис. 3. Структура фази 1 (Aggressive Mode)

Ініціатор з пакета 2 бере необхідну інформацію. Потім обчислює робочі константи, аутентифікаційні інформацію і ключі шифрування. Пакетом 3 ініціатор аутентифікує себе.

Фаза 2 (Quick Mode)

Метою другої фази є отримання параметрів секретного з'єднання і ключової інформації [5] [6]. Всі пакети, що передаються під час другої фази, захищаються секретним з'єднанням, створеним під час першої фази. Одночасно із забезпеченням конфіденційності переданої інформації забезпечується і цілісність даних шляхом передачі значення хеш-функції від даних.

Рис. 4. Структура фази 2 (Quick Mode)

Режим складається з трьох пакетів. Його структура представлена ​​на малюнку 4. У першому пакеті ініціатор посилає SA payload, що містить пропозиції про параметри майбутнього з'єднання, випадкову інформацію (Nonce payload) для створення ключової інформації. Всі інші компоненти пакету є опциональнимі. Якщо для розрахунку ключової інформації потрібно використовувати «свіжий» ключовий матеріал, то здійснюється ще один обмін відкритими ключами, в іншому випадку для розрахунку береться інформація з першої фази. Також, якщо локальна політика вимагає використання в другій фазі ідентифікаційної інформації відмінною від інформації використовуваної в першій фазі, додаються відповідні Identification payload-и.

Структура другого пакету аналогічна першому, тільки заповнюється інформацією про відповідача. Виняток становлять тільки компоненти з ідентифікаційної інформацією, які або приймаються (і тоді в такому ж вигляді і відсилаються) або не приймаються і спроба встановлення з'єднання вважається невдалою.

Третій пакет посилається ініціатором на підтвердження правильності прийнятої інформації та містить тільки Hash payload, який обчислюється за допомогою буфера випадкових даних, посланих відповідачем в другому пакеті. Вміст Hash payload-ів обчислюються за такими формулами:

HASH (1) = PRF (SKEYID _ a, Message ID | SA | Ni [| KE] [| IDic | IDcr])

HASH (2) = PRF (SKEYID _ a, Message ID | Ni | SA | Nr | [| KE] [| IDic | IDcr])

HASH (3) = PRF (SKEYID_a, 0 | Message ID | Ni | Nr)

Формула для розрахунку остаточного ключового матеріалу залежить від того, чи був обмін відкритими ключами для створення нового спільного ключа. Якщо такого обміну не було, то формула така:

KEYMAT = PRF (SKEYID _ d, protocol | SPI | Ni | Nr)

де protocol - номер протоколу, для алгоритму якого вважається ключовою матеріал.

Якщо все ж обчислення загального ключа вироблялося, формула для розрахунку остаточного ключового матеріалу наступна:

KEYMAT = PRF (SKEYID _ d, g ^ xy | protocol | SPI | Ni | Nr)

Таким чином, після другої фази ми отримуємо всю необхідну інформацію для створення секретного з'єднання. Список застосовуваних протоколів і використовуються в них алгоритми виходить після обміну SA payload-ами у другій фазі. Ключова інформація для кожного алгоритму розраховується за наведеними вище формулами. Слід зауважити, що наведена вище структура протоколу була спрощена для простоти сприйняття (відсутній розгляд решти методів аутентифікації і New Group Mode).

Види мережевих атак

Не дивлячись на те, що протокол сам по собі не виробляє захист переданої інформації, а лише створює з'єднання для передачі даних, він сам є предметом атаки. Піддатися атаці в протоколі можуть процес аутентифікації, процес забезпечення цілісності та конфіденційності інформації, що передається і, нарешті, сама працездатність протоколу. У цьому розділі ми розглянемо основні види мережевих атак і те, як протокол їм протистоять [4].

Відмова в обслуговуванні (Denial of Service)

Дана атака є однією з найбільш простих і ефективних. Метою атаки є працездатність системи або, в даному випадку, протоколу.

Сама атака являє собою посилку зловмисником великого числа запитів на створення з'єднання, змушуючи протилежну сторону витрачати ресурси на їх обробку. Щоб приховати свій справжній адресу пакети можуть надсилатися з фіктивних адрес. Якщо їх посилають помилкові запити займають собою всі ресурси системи, то обробка приходять правильних запитів відкладається на невизначений час або вони просто ігноруються. З боку зовнішнього світу система виглядає непрацюючої.

Обмовимося відразу, способу, повністю захиститься від даного типу атак не існує. Атаку можна лише зробити менш ефективною. У протоколі ISAKMP це досягається в першу чергу за рахунок відкладання основних «важких» розрахунків на більш пізні обміни. У перші обміни виробляються прості обчислення (вибір параметрів з'єднання). У той же час сама робота протоколу складається з декількох обмінів, що не дозволяє зловмисникові використовувати фіктивні адреси, тому що не отримавши інформацію від нас, він не зможе правильно сформувати наступний пакет. Тобто якщо атака і стане успішною, ми будемо точно знати, хто нас атакував. Однак слід зауважити, що даний спосіб захисту не підходить для Aggressive Mode, який, як уже підкреслювалося, працює швидше, але менш захищений.

Людина посередині (Man-in-the-Middle)

Метою атаки є конфіденційність і цілісність даних. Атака полягає в тому, що зловмисник, вклинюючись у процес встановлення секретного з'єднання, представляється для кожної з сторін її партнером і проводить встановлення з'єднання від її імені. У результаті замість одного захищеного каналу між двома партнерами виходить два канали між кожною з сторін і зловмисником. Для кожного з партнерів все виглядає звичайним чином, але зловмисник отримує можливість не тільки переглядати дані, передані по «захищеного» каналу, але навіть модифікувати їх. Структура описаної атаки представлена ​​на рисунку 5.

Sx - секретний ключ, Px - відкритий ключ

Захист від даного виду атаки в протоколі ISAKMP полягає в процесі аутентифікації. Обов'язкове виконання цього процесу під час першої фази гарантує обом сторонам відсутність «людини посередині», який зміг би прослуховувати і модифікувати передані дані не тільки в другій фазі, але і при передачі основної інформації. У даному випадку стійкість протоколу до даного типу атаки визначається надійністю методу аутентифікації. Для методу заздалегідь відомого секретного ключа це визначається унікальністю даного ключа, для методів, які використовують сертифікати - достовірністю отриманого сертифіката.

Повтор посилки (Replay attack)

Атака полягає в перепосилке раніше записаних пакетів з розрахунку на неправильну реакцію атакується. Наприклад, спробувати з допомогою пакетів, підслуханих при аутентифікації двох партнерів, представитися одним з них при встановленні з'єднання з другим. Навіть якщо таким чином просто повторять вже проведене з'єднання (тобто в результаті буде створено ще одне з'єднання збігаються з колишнім), це призведе до втрати ресурсів.

Для захисту від цієї атаки в протоколі був введений Nonce payload, за допомогою якого сторони обмінюються випадкової інформацією. Ця інформація потім бере участь в розрахунках всіх констант і ключових матеріалів. Використання в кожному обміні «свіжої» випадкової інформації гарантує захист від атак за допомогою переповторов.

У першій частині даного розділу була розглянута структура протоколу створення захищених мережевих з'єднань ISAKMP. У процесі розгляду були приведені порядок посилки пакетів, їх вміст і пояснено призначення кожного компонента пакета. Також було дано формули, за якими проводяться розрахунки внутрішніх констант і остаточного ключового матеріалу.

У другій частині були представлені основні типи мережевих атак, пояснений принцип їх дії і, на основі структури протоколу ISAKMP, показано як він протистоїть цим атакам.

Розробка програми

Визначення місця програми в системі захисту мережевого трафіку

У цьому розділі ми розглянемо, з яких основних модулів складається система захисту мережевого трафіку, призначення цих модулів і яким чином вони взаємодіють [3].

На малюнку 6 представлена ​​структура системи захисту мережевого трафіку. Розглянемо окремо кожен модуль.

Модуль управління

Даний модуль визначає загальну поведінку системи. Всередині нього відбувається зчитування, перевірка і зберігання конфігураційної інформації, згідно з якою він керує іншими модулями. Модуль має інтерфейси майже до всіх інших модулів. У модуль обробки трафіку він прогружает правила фільтрації трафіку (вхідного та вихідного), правила обробки трафіку (задані вручну в конфігурації і отримані модулем ISAKMP). З модуля обробки трафіку він отримує запити, на створення секретного з'єднання (правила обробки трафіку), які передає в модуль ISAKMP. Також в процесі роботи модуля ISAKMP саме на ньому лежить обов'язок формулювання пропонованих варіантів параметрів з'єднання і вибір прийнятного варіанту в запропонованому наборі. До прогрузки секретного з'єднання, створеного модулем ISAKMP, воно зберігається в модулі зберігання основної ключової інформації.

Модуль зберігання основної ключової інформації

Є дублюючим місцем зберігання правил обробки трафіку (ще одне знаходиться в модулі обробки мережного трафіку). Необхідність дублювання інформації в двох місцях пояснюється тим, що час життя з'єднання в секундах легше відслідковувати в цьому модулі, а в кілобайтах в модулі обробки трафіку. Додатково з'являється можливість не зберігати в модулі обробки трафіку інформації про з'єднання, якими давно не користувалися, а запрошувати цю інформацію за потребою. Взаємодія ведеться тільки з модулем управління, від якого приймається інформація про з'єднання для збереження і команди на видалення з'єднання, а видається сигнал про те, що в якогось з'єднання минула життя.

Модуль обробки мережного трафіку

Обробляє вхідний і вихідний трафіки згідно з правилами фільтрації і правилам обробки трафіку, які прогружает модуль управління. Для протистояння атакам відмови в доступі, якщо для вхідного пакету не знаходиться правила його обробки, то він просто ігнорується. Навпаки, якщо подібна ситуація відбудеться для вихідного пакету, то в модуль управління передасться запит на створення такого з'єднання. Також в модуль управління може надійти сигнал про те, що у будь-якого сполуки минув час життя в кілобайтах. Від модуля управління даний модуль може отримати створене з'єднання і сигнал на знищення з'єднання.

Модуль ISAKMP

За запитом з боку модуля управління і використовуючи інформацію з конфігурації, створює правила обробки трафіку. Взаємодіє з модулем управління і модулем зберігання ключової інформації ISAKMP. У модуль зберігання ключової інформації зберігаються внутрішні з'єднання, створені під час першої фази і використовуються для захисту наступних фаз. Від модуля управління отримує запит на створення з'єднання, інформацію з конфігурації для формування / вибору параметрів з'єднання і формування / перевірки ідентифікуючої інформації та інформацію для аутентифікації себе. Зворотно в модуль управління віддається створене з'єднання або сигнал про невдалу спробу його створення.

Модуль зберігання ключової інформації ISAKMP

Даний модуль є сховищем інформації про секретні з'єднаннях протоколу ISAKMP, які використовуються ним для захисту свого трафіку. Дані сполуки повністю сховані для модуля управління. Модуль здійснює прийом на зберігання інформації про з'єднання, пошук існуючого з'єднання і відстеження закінчення часів життя збережених з'єднань (при закінченні терміну підключення відразу віддаляється).

На основі представленої структури можна описати, яким чином програма, що реалізує протокол ISAKMP, вписується в систему захисту мережевого трафіку. Програма об'єднує собою модуль ISAKMP, модуль зберігання ключової інформації ISAKMP і частина модуля зберігає конфігураційну інформацію необхідну для роботи модуля ISAKMP, здійснює запити на створення нового з'єднання та прийому створених правил обробки трафіку. Таким чином, виходить тільки один інтерфейс з усією іншою системою, що описує взаємовідносини між частиною модуля управління увійшла до складу програми і залишилася частиною модуля управління.

Розробка загальної структури програми

Так як представлена ​​програма написана з використанням технології «ниток» (Thread), то на початку даного розділу буде дано визначення цьому терміну, описані плюси і мінуси використання цієї технології, а потім розглянуто з яких конкретно модулів (ниток) складається програма, їх призначення та взаємодія між собою.

Що таке нитка (thread)?

Під ниткою (іноді званої ниткою контролю) розуміється незалежна послідовність виконання програмного коду всередині окремого процесу [10]. Нитки розділяють між собою всю пам'ять процесу, і якщо одна нитка пише щось на згадку, інша може читати ці дані. Нитки також поділяють всі інші ресурси процесу, наприклад, дескриптор файлу, тобто відразу кілька ниток можуть писати в один і той же файл. Нитки всередині процесу розподіляються і виконуються абсолютно незалежно, тобто якщо одна нитка очікує введення інформації, це ніяким чином не перериває виконання інших ниток. У мультипроцесорних системах різні нитки можуть виконуватися різними процесорами. У однопроцесорних же системах - нитки можуть виконуватися в довільному порядку. Зазвичай, нитка виконується, поки не буде заблокована яких-небудь запитом або поки не закінчиться відведений їй відрізок часу (квант часу).

Не дивлячись на те, що використання ниток трохи ускладнює процес програмування, вони дають переваги. Розглянемо ці переваги докладніше.

Продуктивність. Програма, реалізована за допомогою тільки однієї нитки, переходить в режим очікування при кожному системному виклику. Використання більш однієї нитки (і для мультипроцесорних, і для однопроцесорних систем) дозволяє поєднати часи очікування виконання системних викликів. Нитка, яка робить запит, переходить в режим очікування, але інша нитка в даному процесі може продовжувати роботу. При цьому одному процесу в кожен момент часу може відповідати декілька запитів до системи. Слід зауважити, що дані запити залишаються синхронними.

Мультипроцесорні системи. Використання декількох ниток в одному процесі є ефективним способом використання можливості паралельної роботи.

Графічний інтерфейс для користувача. Однониткових програма, яка надає користувачеві графічний інтерфейс, звичайно завмирає при очікуванні реакції від користувача (наприклад, натискання кнопки). Якщо б цей додаток був багато Стек гілок, то з очікуванням натиснення кнопки можна було б пов'язати окрему нитку, а інші нитки продовжували б працювати. Так само в подібних системах безліч ниток дозволило б зробити непомітним для користувача виконання службових дій (наприклад, автоматичне збереження).

Оперативність серверних додатків. Серверні програми обробляють запити, які надходять від клієнтів. Одночасно може прийти декілька запитів. У разі однониткових програми запити будуть виконуватися послідовно, і виконання складного запиту може надовго відкласти виконання інших, більш простих і важливих запитів. Багато Стек гілок структура в цьому відношенні представляється більш адаптивної, тому що кожен запит користувача може бути оброблений згідно його складності і важливості. Іншою проблемою для серверних додатків є взаємні запити. Це відбувається якщо сервер 1, обробляючи клієнтський запит, робить запит до сервера 2, який у свою чергу при його обробці звертається назад до сервера 1. У однониткових додатку це приведе до зависання обох серверів, тому що єдина нитка сервера 1 вже зайнята обробкою запиту і не може обробити запит сервера 2. Використання декількох ниток вирішує цю проблему, тому що для кожного запиту виділяється окрема нитка, яка виконується незалежно від інших.

Проте використання ниток несе в собі кілька небезпек, і головна з них це робота із загальною пам'яттю. Розглянемо конкретний приклад. Оператор збільшення змінної на одиницю для програми виливається в 3 дії:

1. Завантажити значення змінної в регістр

2. Збільшити регістр

3. Записати значення регістра в змінну

Якщо дві нитки почнуть виконувати цей оператор одночасно, то може відбутися наступна послідовність дій:

Нитка 1 Нитка 2

1 Завантажити значення змінної в регістр

1 Завантажити значення змінної в регістр

2 Збільшити регістр

3 Записати значення регістра в змінну

2 Збільшити регістр

3 Записати значення регістра в змінну

У цьому випадку нитка 1 перезапише значення записаної ниткою 2, і змінна збільшиться лише на одиницю замість двох. Такі місця в коді називають критичними секціями і організують роботу так, що вони гарантовано виконуються тільки однією ниткою.

Використання багатонитковою принципу побудови моєї програми викликано двома причинами:

• Необхідність постійно прослуховувати потрібний порт на наявність пакету, що прийшов.

• Принцип дії програми схожий на принцип роботи серверного додатка (в якості запитів клієнтів виступають приходять пакети). У зв'язку з цим стає дуже цінним можливість обробки пакетів згідно з їх важливості.

Механізм обміну інформації між нитками

У процесі роботи програми нитками необхідно обмінюватися інформацією. В основному це передача пакетів і запитів з параметрами. Для здійснення обміну використовувався механізм pipe [8]. Pipe являє собою модуль для передачі даних. Єдиним його обмеженням є те, що цей модуль створює односпрямований потік даних. Створення проводиться за допомогою функції pipe.

# Include <unistd. H>

int pipe (int filedes [2]);

Функція повертає 0 в разі успіху і -1 при помилці. Параметрами у функцію віддається масив з двох дескрипторів, які заповнюються всередині функції. У перший дескриптор (filedes [0]) призначений для читання з pipe, а другий (filedes [1]) для запису в pipe. Читання з pipe і запис в нього здійснюються за допомогою стандартних функцій read і write. Для цих функцій дескриптор pipe нічим не відрізняється від дескриптора файлу.

# Include <unistd.h>

ssize_t read (int fildes, void * buf, size_t nbyte);

ssize_t read (int fildes, void * buf, size_t nbyte);

Другим параметром у функції передається покажчик на буфер, куди записувати дані (для read) або звідки зчитувати їх (для write). Третім параметром для read передається максимальне число читаються даних, я для write число записуваних байт.

Вибір pipe як засіб передачі між нитками обумовлений простотою і наочністю даного методу. Плюс коректно обробляють ситуацію, коли в pipe пишуть відразу 2 повідомлення - ці повідомлення не перемішуються, а записуються послідовно. Правда в цьому випадку постає завдання поділу цих двох повідомлень, т. к. read не розділяє їх, а, прочитавши відразу два можна або не помітити друге повідомлення або порахувати невірної структуру першого. Для уникнення цього формат повідомлення, що передається в pipe в моїй програмі наступний.

Рис. 8. Структура переданих запитів

Першим байтом у повідомленні йде тип даного повідомлення, який говорить, які саме дані міститися. Якщо тип повідомлення не передбачений у місці, куди це повідомлення прийшло, повідомляється про помилку і з pipe зчитується буфер максимальної довжини. Наступні за типом повідомлення 4 байти містять довжину переданих даних. Якщо тип повідомлення накладає будь-які обмеження на довжину даних (наприклад, якщо передається IP адреса, то його довжина повинна бути 4 байта) і лічена довжина цих обмежень не задовольняє, то також повідомляється про помилку, і намагаємося всі віднімати з pipe. Після цього з pipe дістаються дані вказаної довжини. Після обробки зчитаного запиту процедура повторюється заново, починаючи з одержання типу повідомлення. Такий формат повідомлення і наведений порядок його обробки гарантує, що ніяке повідомлення не буде втрачено.

Стек гілок структура програми

У цьому розділі буде розглянуто, з яких ниток складається програма, їх призначення і як вони взаємодіють один з одним. На малюнку 9 представлена ​​Стек гілок структура програма.

Рис. 9. Стек гілок структура програми

На малюнку колами умовно показані нитки, одинарними стрілками передача даними між нитками, а подвійними взаємодія з таблицею (додавання, пошук та видалення). Програма містить 4 види ниток:

4. Нитка роботи з мережею

5. Нитка розподілу пакетів

6. Нитка виконання першої фази

7. Нитка виконання другої фази

Нитка роботи з мережею. Завданням даної нитки є безперервна перевірка порту на наявність пакета і прийом запитів від інших модулів на відсилання пакетів. Робота даної нитки починається з відкриття порту (функція socket) і вказівки адреси і порту, з яким ми будемо працювати [9].

struct sockaddr_in serveraddr;

if ((sockdscr = socket (AF_INET, SOCK_DGRAM, 0)) == -1) {

printf («Server error: cannot open socket \ n");

return NULL;

}

memset (& serveraddr, 0, sizeof (serveraddr));

serveraddr.sin_family = AF_INET;

serveraddr.sin_port = htons (Conf. LocalPort);

serveraddr.sin_addr.s_addr = inet_addr (Conf. LocalAddress); if (bind (sockdscr, (struct sockaddr *) & serveraddr, sizeof (serveraddr ))==- 1) {

printf («Server error: cannot bind \ n");

return NULL;

}

Як видно з даного частини вихідного коду програми, локальний IP адреса і номер порт беруться з конфігурації. Після ініціалізації нитка повинна увійти в режим очікування і реагувати тільки на дві події прихід пакету та отримання запиту на відправку пакета. Ця дія виконується за допомогою функції select. Вона призначена для спостереження за декількома дескрипторами одночасно на предмет їх готовності до читання, запису або якщо відбулася помилка.

# Include <sys/time.h>

int select (int nfds, fd_set * readfds, fd_set * writefds,

fd_set * errorfds, struct timeval * timeout);

Перший параметр у цій функції - максимальний номер розглянутих дескрипторів. Три наступні параметри - масиви дескрипторів. Перший містить номери дескрипторів, які потрібно спостерігати на предмет можливості читання з нього, другий на предмет можливості запису в нього і третій на предмет виникнення в них помилок. Останній параметр задає часовий інтервал, через який функція повинна закінчитися, якщо не відбудеться ніякої події. Цей параметр дозволяє використовувати дану функцію як таймер. У разі спрацювання якої-небудь події повертається число спрацювали дескрипторів, і в масивах залишаються тільки ці спрацювали дескриптори. При виході з таймаут функція повертає нуль. У випадку помилки повертається -1.

Вся нитка, таким чином, являє собою виконання функції select, яка перевіряє на можливість читання з дескриптора порту і читає кінця pipe, що передає дані в цю нитку. Оскільки вихід з таймаут в даному випадку нам не потрібен, п'ятим параметром передається NULL.

FD _ SET (sockdscr, & rfds) / * Додавання в масив дескриптора порту * /

FD _ SET (pipefd [0], & rfds) / * Додавання в масив дескриптора pipe * /

retval = select (1024, & rfds, NULL, NULL, NULL);

if (SOCKET_ERROR == retval) {

/ * Обробка помилки * /

}

if (FD_ISSET (sockdscr, & rfds)) {

/ * Дії, що виконуються при прибутті пакету * /

}

if (FD_ISSET (pipefd [0], & rfds)) {

/ * Дії, що виконуються при отриманні запиту * /

}

У разі приходу пакету він цілком передається нитки розподілу пакетів (разом з ним передаються також IP адреса і номер порту відправника). При отриманні запиту на посилку пакету пакет відсилається, причому адресу і номер порту одержувача повинен перебувати у запиті.

Нитка розподілу пакетів. У завдання даної нитки входить попередній розбір заголовка пакету, перевірка правильності структури пакета і передача пакета нитки, для якої він призначений. Вся інформація для перевірки пакету і знаходження нитки приймача береться з ISAKMP заголовка пакету. Даний заголовок повинен перебувати на початку кожного пакета і служить для визначення, до якої саме спробі встановлення з'єднання належить даний пакет. Структура ISAKMP заголовка наведена на малюнку 10 [4].

Перші 8 байт займає Initiator Cookie - іідентіфікатор спроби встановлення з'єднання з боку ініціатора. Значення даного поля вибирається на стороні ініціатора (випадковим або визначеним чином) і служить при подальшому розподілі пакетів. Responder Cookie грає таке ж значення, але для відповідача.

Рис. 10. Структура ISAKMP заголовка

Наступним полем іде Next Payload, яке показує тип компонента (payload) наступного за заголовком. Version показує версію використовуваного протоколу. Exchang e type говорить про режим, при якому використовується даний пакет (Main Mode, Aggressive Mode, Quick Mode і т.п.). Прапори містять інформацію про стан пакету, наприклад, зашифрований він чи ні. Ще одним ідентифікатором пакета є Message ID. Останні 4 байти містять довжину всього пакету, включаючи сам заголовок.

Ідентифікація пакету проводиться за такими принципами. У першому пакеті ініціатор проставляє Initiator Cookie, а Responder Cookie залишає нульовим, даючи можливість відповідачу при відповіді заповнити його. Message ID служить для ідентифікації різних спроб встановлення з'єднання у другій фазі, що йдуть під захистом однієї і тієї ж першої фази, а, отже, мають однакові CookieI і CookieR.

Порядок обробки пакета наступний

1. Перевірка довжини пакета. Проводиться простим порівнянням довжини отриманого пакета, яку ми дізнаємося при читанні пакету з порту і значенням відповідного поля в ISAKMP заголовку. Ця перевірка є дуже простий, але в той же час досить ефективною, оскільки дозволяє швидко (фактично на самому першому етапі), без затрачивания великих ресурсів відсікти випадкові пакети. Тут ми вперше зустрічаємося з проблемою різного способу зберігання чисел на різних архітектурах. Якщо розглянути конкретний приклад, то число 0 x 01020304 в системі з процесором Sun Sparc буде представлено у вигляді

тобто спочатку йдуть старші цифри (так зване big - endian подання), а для процесора Intel

спочатку йдуть молодші цифри (little - endian). Через вимоги підтримувати обидві платформи використовувати просте проведення пам'яті до типу unsigned int не можна, тому що значення довжини пакету, наприклад, 100 для Sun Sparc буде 100, а для Intel 1677721600. Для вирішення цієї проблеми були написані макроси для переведення чисел з одного стану в інший для обох платформ.

# Define GET_32BIT (cp) \

(((Unsigned long) (unsigned char) (cp) [3]) | \

((Unsigned long) (unsigned char) (cp) [2] <<8) | \

((Unsigned long) (unsigned char) (cp) [1] <<16) | \

((Unsigned long) (unsigned char) (cp) [0] <<24))

# Define GET_16BIT (cp) \

(((Unsigned long) (unsigned char) (cp) [1]) | \

((Unsigned long) (unsigned char) (cp) [0] <<8))

# Define PUT_32BIT (cp, value) \

(Cp) [3] = (value); \

(Cp) [2] = (value)>> 8; \

(Cp) [1] = (value)>> 16; \

(Cp) [0] = (value)>> 24;

# Define PUT_16BIT (cp, value) \

(Cp) [1] = (value); \

(Cp) [0] = (value)>> 8;

Якщо перевірка не пройшла, то подальший розгляд пакету закінчується і пакет видаляється.

2. Перевіряємо допустимість значень деяких інших полів заголовка - Next Payload, Version, Exchange Type і Flags. Ці поля перевіряються не на точний збіг, як довжина пакету, а на входження значення в діапазон допустимих значень. Перевірка коректності даних значень буде проведена пізніше, при детальному розгляді структури пакету

3. Пошук в таблиці ниток першої фази можливого отримувача пакету. Пошук ведеться на основі значень CookieI і CookieR. Оскільки деякі пакети можуть являти собою запити на створення з'єднань з іншого боку (тобто нитка для їх обробки ще не створена), переповтори цих запитів (нитка вже створена і вже проставлено значення CookieR, тобто в дану нитку пакет не потрапить) , а також відповіді на наші запити (CookieR в таблиці стоять нульові), то порядок пошуку відповідного запису в таблиці наступний: «якщо значення CookieR в пакеті чи таблиці нульове, то запис вважається спрацювала, якщо співпало тільки значення Cookie I, інакше повинні співпасти значення і CookieR, і CookieI ». Якщо ми знайшли спрацювала запис, то ми отримаємо дескриптор запису для pipe, що зв'язує з потрібною ниткою, за яким і передамо пакет. Якщо запис не знайдений і значення CookieR дорівнює нулю це означає, що це перший пакет нової спроби встановлення з'єднання. Для даного пакету ми створюємо нову гілку, pipe для зв'язку з цією ниткою, робимо додавання запису у таблицю ниток першої фази, після чого передаємо пакет щойно створеної нитки. Якщо не виповнилося жодного з перерахованих вище умов, то пакет вважається невірним і віддаляється.

Таким чином, відбувається обробка пакету, що прийшов, але нитка розподілу пакетів може також отримати запит на створення секретного сполуки як ініціатора. У цьому випадку створюється нитка, pipe для зв'язку з нею і нитки передається порожній пакет, як знак початку роботи в якості ініціатора.

Нитка виконання першої фази. Дана нитка призначена для проведення першої фази встановлення з'єднання.

Як було зазначено вище нитки можна представити як незалежне виконання програми. Але, не дивлячись на це, кожна нитка має свій власний стек, а значить всі змінні, оголошені в функції належать тільки нитки. Цей факт використовується для зберігання інформації, пов'язаної тільки з даною спробою встановлення з'єднання (ключі шифрування, робочі константи, метод аутентифікації, поточні CookieI і CookieR і т.д.).

Обробка пакету, що прийшов починається з більш ретельної перевірки пакета. Спочатку перевіряється те, що не змінився тип обміну (якщо це перший пакет, то дане значення зберігається для подальших перевірок). Те ж саме робиться із значенням версії в ISAKMP заголовку. Після цього відбувається розшифрування пакета (якщо це потрібно). Далі відбувається розбір пакета, виконання проміжних дій (розрахунків), складання та відсилання відповідного пакету. Так як набір функцій, що реалізують перераховані вище дії, відрізняється для кожного пакета, побудовою простого циклу завдання не вирішується. Для вирішення цієї проблеми була введена змінна, яка відбивала поточні стан обміну, і за значенням якої можна було дізнатися які функції виконувати. Для наочності та простоти роботи з цієї змінної були описані ряд define.

# Define INITIATOR 0 x 0

# Define RESPONDER 0 x 80

# Define MAIN 0 x 0

# Define AGGRESSIVE 0 x 40

# Define ABSENT 0 x 0 / * Метод аутентифікації ще не визначений * /

# Define PRESHARED 0x8

# Define DSA_SIGN 0x10

# Define RSA_SIGN 0x18

# Define RSA_ENC 0x20

# Define RSA_REV_ENC 0x28

# Define RENCRYPT 0x30

# Define GET_ROLE (State) (State & 0x80)

# Define GET_EXCH (State) (State & 0x40)

# Define GET_MODE (State) (State & 0x38)

# Define GET_STEP (State) (State & 0x03)

# Define SET_ROLE (State, Role) {State & = 0x80; State + = Role;}

# Define SET_MODE (State, Meth) {State & = 0xC7; State + = Meth;}

# Define SET_EXCH (State, Meth) {State & = 0xBF; State + = Meth;}

# Define STATE (role, exch_type, mode, step) (role + exch_type + mode + step)

Приклад використання даної змінної при роботі з програмою буде приведений далі. Перехід до необхідного набору функцій здійснюється за допомогою оператора вибору switch. У кінці кожного набору функцій мінлива поточного стану повинна переводитися в наступний стан (найчастіше це просто збільшення номера пакета) або повинен виставлятися прапор, що говорить про закінчення першої фази.

/ * Отримання про попередня обробка пакету * /

switch (state. State) / * Вибір набору необхідних функцій * /

{

case STATE (RESPONDER, AGGRESSIVE, ABSENT, 0):

/ * Набір функцій для даного стану * /

break;

case STATE (RESPONDER, MAIN, ABSENT, 0):

/ * Набір функцій для даного стану * /

break;

... ... ... ... ... ... ... ... ...

case STATE (INITIATOR, MAIN, DSA_SIGN, 2):

/ * Набір функцій для даного стану * /

break;

}

Змінна поточного стану також активно використовується при розрахунках, де формули відрізняються в залежності від методу аутентифікації або виконуваній ролі (ініціатор або відповідач). Перевести створеного пакету здійснюється через доступний кожної нитки дескриптор запису pipe нитки роботи з мережею

Після закінчення першої фази нитка переходить в режим управління нитками другої фази. Пакети для цих ниток за значенням CookieI і CookieR приходять в дану нитку, а потім за значенням Message ID відправляються в нитки другої фази або ініціюють їх створення. Для проведення правильної ідентифікації пакетів кожна нитка першої фази містить свою таблицю ниток другої фази, по якій і проводить пошук.

Нитка виконання другої фази. Завдання даної нитки - проведення другої фази встановлення з'єднання. Структура і принцип роботи повністю такі ж, як і в нитки першої фази. При створенні разом з пакетом нитки передаються також значення деяких змінних (робочі константи, ключі шифрування і т.п.) необхідні для нормальної працездатності нитки. По завершенню другої фази нитка видає отримані результати, видаляє себе з таблиці ниток другої фази і закінчує роботу.

Таблиці пошуку ниток

Таблиця ниток виконують першу фазу являє собою список CookieTable _ t структур

struct CookieTable_t;

typedef struct CookieTable_t {

uchar CookieI [8]; / * Initiator Cookie * /

uchar CookieR [8]; / * Responder Cookie * /

int pd; / * Pipe Descriptor * /

uchar Ready; / * Ready Flag * /

struct in_addr AlienAddr; / * Peer IP Address * /

struct CookieTable_t * next / * Next Member (NULL if last) * /

};

Непоясненим в даній структурі залишилися два поля: прапор Ready і структура IP адреси. У структурі IP адреси знаходиться адресу партнера, з яким ми ведемо процес встановлення з'єднання. Прапор Ready показує, закінчилося чи ні проведення першої фази. Він використовується, якщо з боку модуля управління прийшло 2 запиту на ініціацію спроби встановлення з'єднання. У цьому випадку проглядається таблиця ниток першої фази в пошуках записи з вказаним IP адресою. Якщо прапор Ready в даній запису говорить про те, що перша фаза вже завершена, то запит формується на проведення відразу другої фази. IP адреса може також використовуватись при пошуку нитки для пакету, що прийшов.

Нижче наведено приклад функції пошуку запису у таблиці за збігом і CookieI і CookieR.

CookieTable_t * FindCookieRecord (uchar * CI, uchar * CR) {

uchar Test [8] = {0, 0, 0, 0, 0, 0, 0, 0};

struct CookieTable_t * ptr = CookieTable;

while (ptr) {

if (MEMCMP (CI, ptr-> CookieI, 8) | |

(MEMCMP (Test, ptr-> CookieR, 8) & & MEMCMP (CR, ptr-> CookieR, 8)))

ptr = ptr-> next;

else

return ptr;

}

return NULL;

}

Таблиця ниток другої фази теж являє собою список структур.

struct Phase2Table_t;

typedef struct Phase2Table_t {

uchar MessageID [4]; / * Message ID * /

int pd; / * Pipe Descriptor * /

struct SPIlist_t SPIlist; / * List of SPIs * /

struct Phase2Table_t next / * Next Member (NULL if last) * /

};

Метод роботи зі списками Phase 2 Table _ t аналогічний вищенаведеному прикладу.

Вхідні і вихідні дані

Спільними вхідними даними (ті які використовуються для ініціатора і для відповідача) є список можливих параметрів з'єднання для першої і другої фаз. Дана інформація зчитується з конфігураційного файлу при запуску програми і зберігається в глобальних змінних, доступна для всіх ниток. Структури, що описують цю інформацію, повторюють структуру SA payload, які призначені для передачі цих самих варіантів параметрів і вибраного випадку. Розглянемо структури для опису параметрів з'єднання докладніше.

typedef struct Proposal _ t {

uchar ProposalN; / * Номер Proposal * /

uchar ProtocolID; / * Номер протоколу * /

NewGroup_t * NewGroup;

uchar NTransforms;

Proposal_t * nextPor;

Proposal_t * nextPand;

Transform_t * nextT;

};

Структура Proposal_t описує Proposal payload, що входить в склад SA payload. Дана структура містить всі поля необхідні для створення і заповнення даного компонента пакета. Полями структури є номер компонента (ProposalN), ідентифікатор протоколу, репрезентованої цим компонентом (ProtocolID), покажчик на структуру містить параметри для New Group Mode (якщо він дорівнює NULL, дані режим не потрібен), кількість Transform payload. Для зв'язку між собою в даних структурах передбачено два покажчика - вказує на наступну структуру об'єднану «І» (nextPand), і який вказує на першу структуру наступної групи, об'єднаної за АБО (nextPor). Також є вказівник на список відповідних Transform payload структур.

typedef struct Transform _ t {

uchar TransformN;

uchar TransformID;

Transform_t * nextT;

Attributes_t * nextA;

};

Структура містить номер структури в даному списку, ідентифікатор акредитуючої алгоритму, покажчик на наступний елемент (нагадаємо, що список одновимірний) і покажчик на приналежний Transform payload список атрибутів.

typedef struct Attributes_t {

uint type;

ushort SmallVal;

BUFFER BigVal;

Attributes_t * nextA;

};

Для атрибутів розрізняють два подання - коротке і довге. При короткому представленні значення атрибута не перевищує 65535 (2 байти), а при довгому задається довжина і буфер, який містить значення атрибута. Те, в якому поданні заданий (присланий) атрибут визначається першим бітом поля type. Якщо він виставлений, то уявлення короткий. Решта біти поля type показують, який це саме атрибут (довжина ключа, метод аутентифікації і т.п.). Поля SmallVal і BigVal призначені для зберігання значення атрибута при відповідно короткому і довгому поданні. Для кожного типу атрибуту визначено його подання. Якщо атрибут вважається довгим, то допускається його подання в короткому форматі (якщо значення вміщується в 2 байти). Але зворотне твердження не вірно - короткий атрибут завжди залишається коротким.

Для зберігання інформації з конфігурації у програмі описані два покажчика на структуру Proposal _ t, які містять набір параметрів відповідно для першої та другої фаз. При отриманні SA payload від партнера, його вміст також переводиться в дані структури для зручності роботи з інформацією.

За допомогою цих же структур відбувається видача результатів роботи програми. Але, оскільки ключовою матеріал не входить до структури, то буфер порахованих ключовим матеріалом передається окремо.

Алгоритм обробки вхідного пакету

При обробці вхідного пакету вирішується два завдання. Перше завдання це відбракувати погані пакети (послані випадково або навмисно) за зовнішніми ознаками, щоб уникнути зайвої витрати ресурсів. Друге завдання це знайти нитку, для якої призначений пакет.

При вирішенні першого завдання розглядаються дві ознаки, за якими пакети перевіряються. Перший - значення поля Initiator Cookie. Це поле ні в одному пакеті не може бути нульовим. Другий пункт при перевірці це довжина пакету. Оскільки її значення передається в ISAKMP заголовку, а він ніколи не шифрується, то для кожного пакету ми можемо дізнатися заявлену довжину і порівняти з довжиною реальною. Друге завдання вирішується на основі значень полів CookieI і CookieR шляхом пошуку необхідної нитки в таблиці ниток першої фази. Спосіб вирішення даних завдань була докладніше розглянута при описі нитки розподілу пакету, тому в цьому розділі буде пояснений алгоритм розбору пакету на його компоненти (payload).

Даний заголовок стоїть на початку кожного компонента і служить для зв'язування компонент до списку. Першим полем у ньому зазначений тип наступного компонента (тип першого компонента вказується у відповідному полі ISAKMP заголовка). В останнього компонента дане поле має дорівнювати нулю. Другий байт в заголовку є зарезервованим для майбутнього використання і має дорівнювати нулю. Останні два байти містять довжину компонента разом із загальним заголовком.

Далі буде розглянута функція CheckPacket, яка здійснює перевірку структури списку компонент.

int CheckPacket (State_t * state)

{

int next = state-> FirstPayload, Length = ISAKMP_HEADER_SIZE;

state-> LastPacket = 0;

state-> ptr = state-> Packet.buf + ISAKMP_HEADER_SIZE;

do

{

if (state-> ptr [1]! = 0) return ERROR / * Поле RESERVED не нуль * /

Length + = GET_16BIT (state-> ptr +2);

if (Length> state-> Packet.len) return ERROR

/ * Вийшли за межі пакету * /

switch (next)

{

case 1: if (CheckSA (state) <0) return ERROR;

state-> LastPacket | = PAYLOAD_SA;

break;

case 4: if (CheckKE (state) <0) return ERROR;

state-> LastPacket | = PAYLOAD_KEY;

break;

... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ....

case 13: if (CheckVendor (state) <0) return ERROR;

state-> LastPacket | = PAYLOAD_VENDOR;

break;

default:

return ERROR;

break;

}

next = state-> ptr [0]

state-> ptr + = GET_16BIT (state-> ptr +2);

} While (next);

return 0;

}

У функцію як параметр передається структура state, яка містить всю інформацію, що відноситься до даної нитки. У даному випадку нам потрібно значення типу першого компонента state -> FirstPayload (воно було отримано при розборі ISAKMP заголовка), покажчик на буфер, що містить пакет, що прийшов і довжина пакету. Оскільки ISAKMP заголовок вже був розібраний, тимчасовий покажчик зміщений на початок першого компонента. Потім починається цикл по всіх компонентах. Спочатку перевіряється правильність загального заголовка. Для цього перевіряємо рівність нулю зарезервованого поля. Довжину компонента додаємо до сумматору загальної довжини пакету (Length) і перевіряємо, що заявлена ​​довжина компонент не більше довжини самого пакету. Потім варто оператор вибору (case), який аналізує значення типу заголовка. Цим виконується перевірка правильності типу компонента, і якщо тип виявляється невідомим (або непідтримуваний), то програма закінчується з помилкою. Для кожного відомого компонента спочатку відбувається перевірка правильності структури компонента. Це обумовлено наявністю в деяких з них зарезервованих полів, а також тим, що деякі з них містять у собі інші компоненти (SA payload). Після перевірки виставляється прапор наявності даного компонента в пакеті. Дані прапори будуть необхідні при семантичному аналізі пакета. Наступним дією ми присвоюємо змінної містить тип наступного компонента нового значення і пересуваємо покажчик на початок наступного компонента. Вихід з даного циклу здійснюється за нульовим значенням поля загального заголовка Next payload. Гарантією того, що процес перевірки взагалі коли-небудь скінчитися служить перевірка того, що довжина розбираємо компонент менше довжини пакета. Нормальний вихід з циклу означає правильну структуру пакету.

Написання програми та проведення тестування

У даному розділі буде описаний процес написання та тестування окремих функцій і модулів. При написанні програми, що реалізує протокол ISAKMP, тестування доводилося проводити після написання майже кожної функції обробки чергового пакета. Спочатку будуть описані службові функції та модулі, а потім модулі безпосередньо реалізують протокол ISAKMP.

Службові функції та модулі.

До службових функцій відносяться функції, що реалізують деякі допоміжні дії, за допомогою яких реалізується сам протокол.

Функції роботи з пам'яттю.

Поряд із системними функціями роботи в моїй програмі були реалізовані функції роботи зі структурою віртуального буфера BUFFER

typedef struct BUFFER {

uchar * buf;

int len;

int Len;

};

Дана структура крім покажчика містить дві довжини - розмір зарезервованого буфера і скільки байт використовується в даний час. Набір функцій виконує стандартний набір дій (створення, копіювання, порівняння, обнулення і видалення), а також конкатенацію двох буферів. Розмір віртуального буфера збільшувався динамічно при додаванні нових даних. Наступний приклад показує це.

int MEMCPY (BUFFER * dst, int offset, uchar * src, int len)

{

uchar * tmp = NULL;

if (! dst) return ERR_BADPARAM;

if (offset + len> dst -> Len) / * Перевірка достатності буфера * /

{

dst-> Len = ((offset + len) / ALLOC_SIZE +1) * ALLOC_SIZE;

tmp = (uchar *) MALLOC (dst-> Len) / * Заняття нового буфера * /

if (! tmp) return ERR_NOMEMORY;

memcpy (tmp, dst -> buf, dst -> len) / * Копіювання старого значення * /

FREE (dst -> buf) / * Видалення старого буфера * /

dst-> buf = tmp;

}

dst-> len = offset + len; / * Нова довжина * /

memcpy (dst -> buf + offset, src, len) / * Копіювання нового значення * /

return 0;

}

Тестування даних функцій вироблялося за допомогою утиліти, яка нараховувала буфери з файлу, і виробляла над ними необхідні дії. Результати за бажанням виводилися на екран або назад у файл, де і аналізувалися.

Функції роботи з мережею.

Включає в себе функції ініціалізації порту, читання та запису інформації. Для тестування було написано дві програми: клієнт і сервер. Завданням клієнта було прослуховування заданого порту і висновок отриманої інформації на екран. Сервер запитував адресу клієнта і відсилав інформацію з файлу за вказаною адресою. Тестування полягало у порівнянні відіслані і отриманої інформації. Також були протестовані випадки приходу відразу декількох пакетів.

Функції криптоалгоритмів

У програмі використовуються алгоритми шифрування DES і Triple DES, алгоритми хешування MD 5 і SHA 1и алгоритми з відкритим ключем RSA та DSA. Реалізація всіх алгоритмів була взята ззовні. Виняток становить тільки Triple DES, реалізація якої заснована на основі функцій реалізації DES.

void des_3cbc_encrypt (DESContext * ks1, DESContext * ks2,

DESContext * ks3, u_char * iv, u_char * dest, const u_char * src, u_long len)

{

word32 iv0, iv1, out [2], out1 [2], out2 [2];

u _ long i;

iv 0 = GET _32 BIT (iv) / * Зчитування значення IV * /

iv1 = GET_32BIT (iv + 4);

for (i = 0; i <len; i + = 8) / * Обробка в циклі по 8 байт * /

{

iv0 ^ = GET_32BIT (src + i);

iv1 ^ = GET_32BIT (src + i + 4);

des _ encrypt (iv 0, iv 1, out 1, ks 1, 1); / * Шифрування першим перемикачем * /

des_encrypt (out1 [0], out1 [1], out2, ks2, 0); / * Розшифрування другого * /

des_encrypt (out2 [0], out2 [1], out, ks3, 1); / * Шифрування третім * /

iv0 = out [0];

iv1 = out [1];

PUT_32BIT (dest + i, iv0);

PUT_32BIT (dest + i + 4, iv1);

}

PUT_32BIT_DES (iv, iv0);

PUT_32BIT_DES (iv + 4, iv1);

}

Тестування алгоритмів шифрування і алгоритмів з відкритим ключем проводилося таким чином. Спочатку тестувалася робота самим із собою, тобто функцією зашифровується буфер, потім розшифровувався і порівнювався з оригінальним значенням. Після цього перевірялася робота з тестовими послідовностями, взятими зі стандарту за даними алгоритмами. Алгоритми хешування відразу тестувалися на стандартних тестових послідовностях.

Створення ниток і організації передачі даних між ними.

Нитка створюється стандартною функцією pthread _ create.

# Include <pthread.h>

int pthread_create (pthread_t * thread_ID, const pthread_attr_t * attr,

void * (* start_func) (void *), void * arg);

Перший параметр в даній функції це якийсь дескриптор нитки, з допомогою якого створює процес (нитка) може потім нею управляти. Третій параметр - ім'я функції, виконанням якої і займеться нова нитка. Як видно з опису функція має певний формат. І останнім параметром передається покажчик на параметри, що передаються цієї нитки при старті. У програмі описано 5 функцій для запуску ниток - робота з мережею, розподілу пакетів, виконання першої фази, виконання другої фази (одна для New Group Mode і одна для Quick Mode). Перші дві нитки створюються при старті програми, інші в міру потреби. Розглянемо приклад створення нитки для першої фази.

# Define THREAD_T pthread_t

# Define THREAD_SIMPLE_CREATE (start_func, arg, tid) \

pthread_create (tid, NULL, start_func, arg)

THREAD_T tid;

... ... ... ... ... ... ... ... ....

Record = AddCookieRecord (); / * Додавання до таблиці ниток першої фази * /

if (NULL == Record) return ERROR_MEMORY;

MEMCPY (Record-> CookieI, buff, 8);

Record-> Ready = 0;

BUFptr = (BUFFER *) MALLOC (sizeof (BUFFER)); / * Створення параметра * /

if (NULL == BUFptr) return ERROR_MEMORY;

MEMINIT (BUFptr);

MEMADD (BUFptr, null, 1);

PUT_32BIT (addr_tmp, clientaddr.sin_addr.s_addr) / * Запис адреси партнера * /

MEMADD (BUFptr, addr_tmp, 4);

PUT_16BIT (null, length);

MEMADD (BUFptr, null, 2);

MEMADD (BUFptr, buff, length) / * Запис довжини пакету * /

if (THREAD_SIMPLE_CREATE (WorkThread, (void *) BUFptr, & tid)) {

printf («Thread creation failed \ n");

return 1;

}

... ... ... ... ... ... ... ... ....

Після прийняття рішення про те, що для прийнятого пакету потрібно створювати окрему нитку я спочатку додаю новий запис у таблицю ниток першої фази. У цей запис заноситися Cookie Initiator і прапор Ready обнуляється як знак того, що перша фаза ще не закінчена. Після цього формується масив, що містить інформацію необхідну для початку роботи нитки. У нього входить IP адреса відіславши повідомлення, довжина пакету і власне пакет. Покажчик на віртуальний буфер, що містить цю інформацію, передається як параметр у функцію нитки. На самому початку роботи кожна нитка створює pipe, для того щоб їй можна було передавати пакети. Той, хто читає дескриптор вона залишає у себе, а дескриптор для запису вона записує в таблицю ниток першої фази (запис вона знаходить, знаючи значення Cookie Initiator). Туди ж записується і значення Cookie Responder, після того як його буде визначено. Для ниток другої фази процес створення багато в чому схожий, за винятком того, що як параметр передається покажчик на структуру state, яка містить всю необхідну інформацію (ключі шифрування, робочі константи, адреси і т.п.). Процес розподілу дескрипторів pipe для зв'язку залишається таким самим. Дескриптор запису в нитку роботи з мережею є глобальної змінної і доступний кожної нитки.

Тестування проводилося шляхом створення простої моделі програми. Простота полягає у відсутності коду реалізує протокол. Нитка просто приймає пакет, збільшує внутрішній лічильник і посилає відповідь. При досягненні лічильника певного значення нитки першої фази починають створювати нитки другої фази, а нитки другої фази, при тому ж значенні лічильника закінчують роботу. Програма для даного тестування стала каркасом майбутньої програми, тому що потім збільшення лічильника було замінено обробкою й аналізом пакета. У даному тесті також проводилося тестування і функцій роботи з пам'яттю і функцій роботи з мережею.

Модулі реалізації протоколу ISAKMP

Дані модулі включають в себе функції аналізу пакету, обробки та перевірки даних, що прийшли, виконання необхідних розрахунків і створення даних необхідних для складання пакета.

Як вже згадувалося раніше, весь процес роботи робочих ниток являє собою перехід з одного так званого стану в інший. Під станом тут розуміється набір певних значень деяких параметрів. У програмі розглядаються наступні параметри: роль грається ниткою (ініціатор або відповідач), тип обміну, номер пакета і метод аутентифікації (тільки для першої фази). Всі параметри, крім останнього, можуть бути визначені на самому початку роботи, тому для методу аутентифікації додається значення NONE, що означає невизначеність параметра. Кожен набір параметрів однозначно вказує на яке-небудь стан.

Стан, у свою чергу, складається з наступних частин: аналіз та перевірка даних з пакета, проведення розрахунків, складання даних для посиланого пакету і визначення наступного стану.

Аналіз та перевірка даних, що прийшли (часто званий «семантичним розбором пакету») включає в себе в першу чергу, аналіз якісного складу пакету, тобто перевіряється чи всі з необхідних у даному стані компонент присутні і чи немає зайвих. Всі ці перевірки здійснюються при аналізі змінної, що містить прапори наявних компонент (те, як вона визначається, описано в розділі, що описує роботу нитки першої фази). Потім проходить перевірка даних, що прийшли. Для кожного компонента відбувається своя перевірка, яка може й не бути, наприклад, Nonce payload значення якого просто запам'ятовується. Для SA payload перевірка полягає в порівнянні прийшла політики з описаною в конфігурації для відповідача і в перевірці правильності надісланого відповіді для ініціатора. Для KE payload відбувається перевірка довжини надісланої ключової інформації відповідно до параметрів, надісланим в політиці. У Certificate та Certificate Request payloads перевіряється тип використовуваних сертифікатів (у мене в програмі допустимі тільки x 509 сертифікати). У Identification payload перевіряється тип присилається інформації (допускається тільки IP адреси) і власне вміст компонента. Компонент зі значенням хеш-функції (Hash payload) перевіряється шляхом підрахунку свого варіанту і порівняння його з прийшли значенням. У прикладі приведена функція, що обчислює значення хеш-функції протилежної сторони.

int CalculateAlienHash (State_t * state, BUFFER * Hash)

{

uchar save;

BUFFER DATA;

MEMINIT (& DATA) / * Ініціалізація буфера * /

if (! ((state-> SKEYID). len))

CalculateSKEYID (state) / * Підрахунок SKEYID * /

MEMADD (& DATA, & (state-> AlienKE)); / * g ^ x (i / r) * /

MEMADD (& DATA, & (state-> MyKE)); / * g ^ x (i / r) * /

if (GET_ROLE (state-> State) == INITIATOR) {

MEMADD (& DATA, state-> CookieR, 8);

MEMADD (& DATA, state-> CookieI, 8);

} Else {

MEMADD (& DATA, state-> CookieI, 8);

MEMADD (& DATA, state-> CookieR, 8);

}

MEMADD (& DATA, & (state-> SAi_b));

MEMADD (& DATA, & ((state-> AlienIdent). Type), 1);

MEMADD (& DATA, (state-> AlienIdent). DOI, 3);

MEMADD (& DATA, & ((state-> AlienIdent). Data));

if (GET_MODE (state-> State) == DSA_SIGN) {

save = state-> HashAlg;

state-> HashAlg = HASH_ALG_SHA;

M (PRF (state, & (state-> SKEYID), & DATA, Hash));

state-> HashAlg = save;

} Else

M (PRF (state, & (state-> SKEYID), & DATA, Hash));

return 0;

}

Формули, реалізовані цією функцією, були представлені при описі фази 1 (Main Mode). Слід зауважити, що ця функція вважає не значення ініціатора або відповідача, а значення хеш-функції протилежної сторони. Усередині функції це досягається аналізом змінної показує поточний стан. Для перевірки підпису (розташовується в Signature payload) вважається дане значення хеш-функції і підписується необхідним алгоритмом. У наведеному прикладі є ще один приклад використання змінної стану. DSA алгоритм може підписувати хеш тільки від алгоритму SHA. Спеціально для цього випадку значення поточного алгоритму хешування примусово прирівнюється значенням алгоритму SHA. Слід зауважити, що в процесі перевірки може помінятися поточне значення стану. Це може статися при порівнянні політик, коли партнери домовляються про метод аутентифікації

Після перевірки проводяться необхідні розрахунки. Більшість формул для розрахунків були приведені в розділі про першій фазі.

int CalculateSKEYID_d (State_t * state)

{

uchar z0 = 0;

BUFFER DATA;

MEMINIT (& DATA);

if (! ((state-> SKEYID). len))

M (CalculateSKEYID (state));

MEMADD (& DATA, & (state-> SharedKey));

MEMADD (& DATA, state-> CookieI, 8);

MEMADD (& DATA, state-> CookieR, 8);

MEMADD (& DATA, & z0, 1));

PRF (state, & (state-> SKEYID), & DATA, & (state-> SKEYID_d));

MEMZERO (& DATA);

return 0;

}

Вище наведено приклад розрахунку однієї з робочих констант.

Розглянемо приклад однієї з реалізації функцій стану. Стан візьмемо для ініціатора, режим - Aggressive Mode, пакет - прихід відповіді від відповідача.

... ... ... ... ... ... ... ... ... ....

case STATE (INITIATOR, AGGRESSIVE, ABSENT, 1):

if (state. LastPacket & PAYLOAD_SA)

{

Log (PAYLOAD_MALFORMED, & state, NULL);

goto THREAD_END;

}

answer = ProvePolicy (& MyISAKMPPolicy, & (state. AlienPolicy), & state);

if (answer == ERR_NOPROPOSAL)

{

Log (PAYLOAD_MALFORMED, & state, NULL);

goto THREAD_END;

}

switch (state. AuthMeth)

{

case 1: SET_MODE (state. State, PRESHARED); break;

case 2: SET_MODE (state. State, DSA_SIGN); break;

case 3: SET_MODE (state. State, RSA_SIGN); break;

case 4: case 5:

default:

Log (NOT_SUPPORTED, & state, NULL);

goto THREAD_END;

}

ONE_MORE = 1;

break;

... ... ... ... ... ... ... ... ....

Даний приклад дуже показовий тим, що тут відбувається зміна значення поточного стану при перевірці пакету. Пакет містить вибрану відповідачем політику, а, отже, і вибраний метод аутентифікації. За цим значенням відбувається зміна значення поточного стану і виставляється прапор, що говорить, що треба повторити оператор вибору стану, щоб виконати дії необхідні саме цим методом аутентифікації.

case STATE (INITIATOR, AGGRESSIVE, PRESHARED, 1):

ERR (CheckHash (& state));

ERR (CalculateEncKeysPhase1 (& state));

ERR (MakeISAKMP (& state));

ERR (MakeHash (& state));

ERR (SendPacket (& state, 0));

NOT_END = 0;

break;

Наведений набір дій буде виконано, якщо в попередньому прикладі партнери домовилися про метод аутентифікації за допомогою заздалегідь відомого секретного ключа. На даному прикладі видно всі три складових стану. Спочатку проходить аутентифікація відповідача шляхом перевірки значення Hash payload. Потім проводиться розрахунок ключової інформації для першої фази. Завершують всі функції створення компонент пакету і відсилання самого пакету. Так як це останній пакет з боку ініціатора, то значення стану не змінюється і виставляється прапор, що говорить про закінчення фази.

Описаний принцип станів використовувався для написання логіки веління у всіх обмінах. Будь-яка робоча нитка мала наступну структуру:

/ * Ініціалізація нитки * /

while (NOT _ END) {/ * Перевірка ознаки закінчення роботи * /

if (GET _ STEP (state. State)) / * Якщо це не перший пакет * /

{

ERR (RecivePacket (& state)); / * Очікування пакету * /

ERR (DecryptPacket (& state)); / * Розшифрування пакету * /

}

ONE_MORE = 1;

while (ONE_MORE) {/ * Новий вибір без посилки пакета * /

ONE_MORE = 0;

switch (state. State) {

case STATE (RESPONDER, AGGRESSIVE, ABSENT, 0):

case STATE (RESPONDER, MAIN, ABSENT, 0):

FreePolicy (state. AlienPolicy);

ERR (CheckPacket (& state));

ONE_MORE = 1;

break;

case STATE (RESPONDER, MAIN, RSA_SIGN, 0):

... ....

state. State + + / * Наступний номер пакету * /

break;

... ... ... ... ... ....

} / * Switch * /

} / * While (ONE_MORE) * /

} / * While (NOT _ END)

/ * Дії виконуються в кінці нитки * /

Основу нитки складає цикл очікування кінця роботи. Усередині нитки спочатку відбувається очікування пакета (якщо це не самий початок обміну), потім йде цикл, що дозволяє проводить наскільки виборів станів. Потім йде безпосередньо вибір стану та виконання відповідних стану набору функцій.

Тестування функцій реалізації протоколу повинні проходити після реалізації кожного стану. На самому початку в тестах допоможе утиліта клієнта, що залишилася від тестів функцій роботи з мережею. Нею можна буде переглядати пакети, якщо ще не створені стану для відповідача. Тестування полягає в запускання процесу встановлення з'єднання (нехай навіть воно явно не завершитися) та аналізі інформації видається програмою в процесі роботи на екран або у файл. У процесі тестування можуть бути виявлені такі типи помилок. Програма просто не працює, тобто присутня якась помилка виконання програми. Якщо вона не очевидна відразу, то її пошук здійснюється за допомогою отладчика. Другий варіант - програма працює, але виробляються неправильні дані або є невірна реакція на правильні дані. У більшості випадків подібна ситуація вирішується аналізом інформації видається програмою в процесі роботи (лог). Якщо з існуючого логу помилка не знаходиться, то можна спочатку спробувати використовувати більш детальний лог. Якщо це не допомагає, то використовується відладчик, хоча використання цього методу для подібних помилок може стати вельми времязанімающім заняттям. Після того, як якийсь етап, був протестований на роботу самим з собою можна, переходити на тестування з іншими реалізаціями протоколу. Причому це робилося також після написання кожного стану.

Тестування з іншими реалізаціями протоколу ISAKMP

Під час написання і налагодження моєї програми, зовнішньою реалізацією для тестування був вибраний сайт www.ssh.fi, містить свою реалізацію даного протоколу. Даний сервер має добре розгалужену систему налаштувань політики чужої сторони, що дозволяє визначати посилається мені SA payload з точністю до атрибутів (що дуже допомогло при тестуванні вибору прийнятних атрибутів). Також на сервері добре реалізована система показу процесу роботи програми. Розрахунок кожної величини передує перерахуванням вхідних даних і використовуваних алгоритмів. Це дуже допомагає при пошуку помилок, пов'язаних з неправильним обчисленням констант або неправильному використанні алгоритмів, коли видно, що вхідні дані ті ж, а результат інший.

Налагодження з даною реалізацією проводилась методом описаному в попередньому розділі. Тобто після кожного створеного стану проводилося тестування при різних вхідних даних.

Висновок

У даному розділі були розглянуті загальні принципи створення програми реалізації протоколу ISAKMP. Розглянуто способи використання багатонитковою структур програми, зазначений необхідний набір функцій для створення нитки і забезпечення передачі даних між нитками. Представлена ​​структура програми, описані використовуються в ній нитки, порядок їх реалізації та інтерфейс спілкування між ними. Розглянуто порядок розробки програми та методика проведення тестування програми в процесі її створення.

Технологія реалізації протоколу ISAKMP

Виходячи з технічного завдання, дана реалізація протоколу ISAKMP повинна містити 4 обміну (Main M ode, Aggressive M ode, New Group M ode і Quick M ode) і повинна підтримувати 4 методу аутентифікації (методом заздалегідь відомого секретного ключа, цифровим підписом за допомогою алгоритмів DSS і RSA, шифрування відкритим ключем за допомогою алгоритму RSA). Весь процес написання програми можна розбити на 6 частин:

1. Підготовча частина

2. Реалізація Main mode з методом аутентифікації заздалегідь відомого секретного ключа

3. Реалізація Quick M ode

4. Реалізація інших методів аутентифікації для Main Mode

5. Реалізація Aggressive Mode з усіма методами аутентифікації

6. Реалізація New Group Mode

При такому порядку написання програми спочатку буде написана версія з мінімальною функціональністю (для найпростішої конфігурації протокол буде працювати вже після третього етапу), а вже потім відбувається виконання всіх вимог технічного завдання.

Підготовча частина

Підготовча частина включає в себе написання допоміжних модулів, які можна виділити в окремі завдання.

• Реалізація криптоалгоритмів. Включає в себе написання функції реалізують алгоритми шифрування DES і Triple DES, алгоритми хешування MD5 і SHA і алгоритми з відкритим ключем RSA та DSA. Реалізація включає в себе перевірку правильності роботи функцій. Для алгоритмів шифрування спочатку відбувається перевірка роботи функцій самих з собою (шифрування довільний текст, розшифрування та перевірка ідентичність), потім перевірка працездатності з іншими реалізаціями даного списку і перевірка тестових послідовностей. Для алгоритмів хешування можлива тільки перевірка тестових послідовностей.

• Реалізація алгоритму Diffie - Hellman. Включає в себе написання функцій підрахунку відкритого ключа за відомим секретного ключа і розрахунку загального ключа для будь-яких заданих параметрів алгоритму. Тестування спочатку здійснюється між собою (розрахунок двох пар ключів, розрахунок загального ключа для обох сторін і перевірка ідентичності), потім з іншими реалізаціями даного алгоритму.

• Робота з мережею. Включає в себе функції ініціалізації та закриття портів, відсилання і прийому пакетів. Тестування полягає у перевірці ідентичності відправлених та отриманих пакетів.

• Конфігурація. Включає в себе зчитування конфігурації з зазначеного файлу, перевірка її правильності та заповнення, згідно з нею, внутрішніх структур.

• Лог. Включає в себе функції ініціалізації і запису в лог-файл. Функція запису пишеться з розрахунком на багато Стек гілок програму.

• Робота з буферами змінної довжини. Сам буфер представляється у вигляді структури. Функції реалізують наступні дії: створення, очищення, копіювання в буфер і з нього, додавання інформації в буфер, роздруківка, видалення. При тестуванні слід написати тестову програму, що реалізовує всі необхідні дії.

• Робота з сертифікатами. Реалізуються функції завантаження сертифіката з файлу, перевірка правильності сертифікату, отримання інформації з сертифікатів. У список перерахованих дій не входить створення сертифікатів, тобто нам доведеться сертифікати, створені третьою стороною. Під час тестування відбувається перевірка працездатності всіх функцій, причому всі тести повинні проходити для сертифікатів, отриманих з різних місць.

• Перевірка структури пакета. Протокол ISAKMP чітко визначає структуру пакетів. Тестування здійснюється шляхом ручного завдання правильно і неправильно сформованих пакетів.

Частина з перелічених вище завдань можна робити паралельно з виконанням основного завдання (наприклад, робота з сертифікатами потрібно лише при реалізації методів аутентифікації цифровим підписом і шифруванням відкритим ключем).

Реалізація Main mode c методом аутентифікації заздалегідь відомого секретного ключа

Main mode складається з 6-та посилок пакетів - 3 від кожної зі сторін (ініціатора і відповідача). Також тут реалізується прийом завдання для сторони ініціатора.

Реалізація на даному етапі тільки одного з 4 методів аутентифікації продиктовано бажанням отримати спочатку працюючу версію, а вже потім додавати в неї необхідну функціональність. Не дивлячись на це, в програмі враховуються всі методи аутентифікації, але замість всіх не потрібних підставляються «заглушки».

Кожен з обмінів реалізується відразу як для ініціатора, так і для відповідача. Після виконання кожного з обмінів відбувається тестування. Спочатку пробується робота двох реалізацій, а потім тестується робота з іншого реалізацією протоколу.

Порядок реалізації даного етапу наступний:

1. Отримання завдання на встановлення з'єднання з боку ініціатора, перевірка необхідності проведення першої фази (можливо для даного партнера ISAKMP SA вже створена і тоді зразу переходимо до другої фази);

2. Складання і відсилання ініціатором першого. Найбільш складним тут є запис політики заданої в конфігураційному файлі в структуру пакету ISAKMP;

3. Прийом і розбір першого пакету відповідачем. Вибір із запропонованої політики прийнятного варіанту. Складання і відсилання другого пакету, що містить вибрану політику;

4. Прийом і розбір другого пакету ініціатором. Перевірка коректності обраної політики. Отримання таємного та відритого ключів для алгоритму Diffie - Hellman з параметрами, обумовленими в політиці. Складання і відсилання третього пакета, що містить свій відкритий ключ і Nonce - випадкову послідовність для даного з'єднання;

5. Прийом і розбір третього пакета відповідачем. Збереження Nonce і відкритого ключа ініціатора, обчислення своєї пари Diffie - Hellman ключів. Складання і відсилання четвертого пакета, що містить відкритий ключ і Nonce відповідача;

6. Прийом і розбір четвертого пакету ініціатором. Обчислення загального ключа для алгоритму Diffie - Hellman за допомогою свого таємного ключа і відкритого ключа відповідача. Отримання аутентифицирующей інформації Складання п'ятого пакета, що містить інформацію, що ідентифікує і аутентифицирующей ініціатора. Обчислення ключів шифрування. Шифрування отриманого пакета за допомогою алгоритмів, обумовлених в політиці, і тільки що обчислених ключів. Перевести зашифрованого пакета;

7. Прийом п'ятого пакету відповідачем. Обчислення загального ключа для алгоритму Diffie - Hellman. Обчислення ключів шифрування. Розшифровка пакета і його розбір. Перевірка ідентифікуючої інформації ініціатора. Обчислення аутентифицирующей ініціатора інформації та порівняння зі значенням знаходяться в пакеті. Обчислення інформації ідентифікуючої і аутентифицирующей відповідача. Складання, шифрування і відсилання шостого пакета;

8. Прийом шостого пакету ініціатором. Розшифровка пакету та перевірка інформації ідентифікуючої і аутентифицирующей відповідача.

Результатом першої фази ставати ISAKMP SA, яка включає в себе алгоритми, про які сторони домовилися під час обміну політиками, і ключова інформація, яка вважається при наступних обмінах. ISAKMP SA використовується для захисту всіх наступних обмінів.

Помилки, спливають у процесі роботи і при тестуванні, можна розділити на помилки впливають на працездатність програми (критичні помилки періоду виконання, помилки доступу до ресурсів - тобто коли програма припиняє свою роботу) і помилки пов'язані з реалізацією протоколу (неправильно складений пакет, неправильний розбір пакету, що прийшов і т.д.). Помилки першого типу в основному виявляються за допомогою отладчика. Помилки другого типу виявити складніше, тому що найчастіше вони ховаються в логіці програми. Першим кроком при їхньому пошуку є ретельне вивчення журналів з ​​обох сторін, оскільки неправильна реакція на пакет, що прийшов на одній із сторін може бути викликана не дотриманням правил складання пакету з іншого боку. Можливо, в процесі аналізу потрібно зробити лог докладнішим для всього процесу встановлення з'єднання або для окремих моментів. У результаті аналізу логу повинно бути знайдено місце, де програма повела себе неправильно. Якщо помилка, що викликала це неправомірна дія очевидна, то вона виправляється. Інакше її пошук триває, але вже за допомогою отладчика.

Після написання всіх трьох обмінів відбувається тестування Main mode в цілому. Спочатку тестується робота двох реалізацій програми в ролі і ініціатора і відповідача. Потім тестується сумісність з іншими реалізаціями протоколу (у процесі розробки для тестування сумісності використовувався сервер www. Ssh. Fi). Тестування включає в себе проведення одиночного з'єднання і відразу декількох (причому кожна з сторін у різних сполученнях відіграє різну роль), проведення вдалих і невдалих з'єднань. Також в процесі тестування перевіряється однакова робота програми на різних процесорах (Sun Sparc і Intel x 86).

Реалізація Quick mode

Quick M ode, що представляє собою другу фазу встановлення з'єднання, складається з 3-х посилок пакетів - дві з боку ініціатора і одна з боку відповідача. Порядок розробки і тестування такий же, як на попередньому етапі. Даний режим проходить під захистом ISAKMP SA, полеченной під час першої фази.

На цьому етапі спочатку реалізується робочий мінімум (тобто без повторного обміну ключовою інформацією і посилки ідентифікаційної інформації), а потім, коли цей мінімум буде повністю оттестирован, доробляються інші частини. Таким чином, порядок реалізації даного етапу буде наступним:

1. Отримання ініціатором з конфігураційного файлу політики для другої фази. Складання першого пакету, що містить пропоновану політику і Nonce. Обчислення значення хеш-функції від пакету, додавання цього значення в пакет і шифрування пакету. Перевести пакету відповідачу.

2. Прийом пакету, розшифрування та перевірка цілісності шляхом обчислення значення хеш-функції від пакету і порівняння з присланим значенням. Вибір з надісланої політики прийнятного варіанту політики. Складання другого пакету, що містить вибрану політику і свій Nonce. Обчислення значення хеш-функції від пакету, шифрування пакету і відсилання його ініціатору.

3. Прийом ініціатором другого пакету. Розшифрування пакету і перевірка цілісності. Перевірка коректності обраного варіанту політики. Обчислення значення хеш-функції від Nonce-ів. Складання третього пакета, його шифрування і відсилання відповідачу. Обчислення вихідних результатів.

4. Прийом відповідачем третього пакета. Розшифровка пакету, обчислення значення хеш-функції від Nonce-ів і порівняння з присланим значенням. Обчислення вихідних результатів.

5. Якщо в конфігурації вказана необхідність в обміні ключами здійснити розрахунок пар ключів з кожної зі сторін, обмін відкритими ключами і здобуття загальної ключа аналогічно тому, як це робилося на попередньому етапі. Також врахувати наявність спільного ключа при розрахунку вихідних результатів.

6. Якщо в конфігурації вказана необхідність посилки ідентифікаційної інформації, то з боку ініціатора забезпечити включення цієї інформації в перший пакет, а з боку відповідача її перевірку.

Всі заходи пов'язані з тестуванням проводяться також як і на першому етапі. Повинні проводитися тести після реалізації кожного взаємного обміну і фінальні тести, що включають в себе одночасне проведення кількох сполук, використання різних конфігурацій (провести другу фазу в різних обсягах), тестування з іншими реалізаціями протоколу та тестування роботи програми на різних процесорах.

Реалізація інших методів аутентифікації для Main mode

На даному етапі додаються можливі методи аутентифікації для першої фази. Всі ці методи використовують алгоритми шифрування з відкритим ключем і сертифікати як спосіб передачі відкритих ключів. Слід зауважити, що необхідність у функціях роботи з сертифікатами і реалізації алгоритмів DSA і RSA зустрічається вперше саме на цьому етапі, що дозволяє распараллеліть роботи над цими завданнями.

Як і на попередніх етапах, спочатку реалізується робочий мінімум, який включає в себе власне обчислення і перевірку аутентификационной інформації, потім додати можливості обміну сертифікатами.

Порядок реалізації даного етапу наступний:

1. Реалізація розгалуження за різними методами аутентифікації в залежності від домовленої політики;

2. Реалізація методів аутентифікації за допомогою підпису алгоритмами DSA і RSA. Включає в себе обчислення підпису кожної зі сторін для спеціально обчислюваного значення хеш-функції й перевірка підпису на іншій стороні. Сертифікати для перевірки підпису іншого боку задаються явно.

3. Реалізація методу аутентифікації шифруванням відкритим ключем алгоритмом RSA. Сертифікати для розшифрування також задаються явно.

4. Реалізація обміну сертифікатами. Включає в себе реалізацію запиту сертифіката іншого боку і відсилання свого сертифіката на запит і без запиту. Інформація про те чи треба посилати свій сертифікат, запитувати чи чужий і т.п. береться з конфігураційного файлу.

Після реалізації цього етапу проходить той же набір тестів, що проводився після закінчення другого етапу. Але в даному випадку робиться акцент на правильність роботи саме знову доданих методів аутентифікації. Особлива увага приділяється правильній діагностиці помилок виникають при не знаходженні сертифікатів та отриманні сертифікат, чий тип відрізняється від очікуваного значення.

Реалізація Aggressive mode з усіма методами аутентифікації

На цьому етапі реалізується інший режим для проведення першої фази. Від Main mode його відрізняє менша кількість надісланих пакетів, але разом з цим більшу кількість інформації передаються у пакетах і велика трудомісткість при їх обробці. Реально цей режим реалізується на основі коду написаного для Main mode шляхом перестановки основних функцій, але при цьому треба пам'ятати, що проста перестановка не допоможе і потрібно якийсь додатковий аналіз. Наприклад, в політиці, переданої ініціатором, не може бути запропонований вибір між різними Oakley групами, тому що в цьому ж пакеті надсилається публічний ключ однозначно визначає групу. Всі подібні перевірки повинні проводитися для Aggressive Mode.

Порядок реалізації етапу наступний:

1. Реалізація розгалуження між Main і Aggressive режимами. Для ініціатора вид режиму визначається конфігурацією. Відповідач перевіряє прийнятність запропонованого режиму, також грунтуючись на конфігурації і, в разі не прийнятного значення, може відмовитися продовжувати обміни. Ініціатор повинен у цьому випадку вміти запропонувати інший режим, звичайно, якщо це дозволяє реалізація.

2. Реалізація методу аутентифікації заздалегідь відомого секретного ключа. Після реалізації проводять тести, проведені на другому етапі, але з використанням Aggressive mode.

3. Реалізація інших методів аутентифікації. Етапи реалізації і тести аналогічні такі ж, як на четвертому етапі.

Як вже згадувалося вище, тести під час розробки і по її закінченню аналогічні тестів проводяться на другому і четвертому етапах, але з акцентом на використання різних режимів в першій фазі. Особливо варто звернути увагу на повторну спробу ініціатора провести з'єднання в іншому режимі після відмови з боку відповідача.

Реалізація New Group Mode

Даний режим призначений для узгодження нестандартних Oakley груп і полягає лише в обміні політиками. Але основна складність полягає у вбудовуванні використання цього режиму і правильному використанні результатів роботи режиму у другій фазі. Сам режим, також як і Quick mode, проходить під захистом ISAKMP SA.

Порядок реалізації етапу наступний:

1. Реалізація з боку ініціатора відгалуження на New Group mode в залежності від конфігурації. Повинна бути передбачена перевірка існування вже створеної нестандартної Oakley групи.

2. Створення ініціатором пакунок, що містить інформацію про пропоновану групі, підрахунок значення хеш-функції від цього пакету, шифрування пакету (з допомогою алгоритмів і ключів з ISAKMP SA) і відсилання пакета;

3. Отримання пакета, його розшифрування і перевірка цілісності. Перевірка прийнятності запропонованої групи. Складання відповідного пакету, підрахунок значення хеш-функції, шифрування і відсилання цього пакета. Збереження інформації про групу для другої фази;

4. Отримання пакета, його розшифрування і перевірка цілісності. Перевірка коректності надісланої інформації. Збереження інформації про групу для другої фази.

5. Реалізація використання під час другої фази груп, про які домовлялися під час New Group mode.

При тестуванні перевіряється правильна робота в New Group mode і ініціатора, і відповідача. Особливу увагу варто приділити правильній роботі програми при спробі домовитися про декілька Oakley групах.

У даному розділі був розглянутий порядок реалізації протоколу ISAKMP, запропонований варіант розбиття загальної задачі на підзадачі, надано рекомендації щодо організації робіт над цими завданнями та запропоновано порядок проведення тестів.

Слід зауважити, що даний порядок реалізації протоколу ISAKMP був запропонований в розрахунку на певні технічні вимоги до програми і в розрахунку на роботу однієї людини. При інших вимогах або якщо кількість працюючих над програмою людина змінюється, порядок реалізації протоколу може істотно змінитися як на рівні етапів, так і на більш низьких рівнях.

Сегментація ринку користувачів програми, що реалізує протокол ISAKMP

Успіх просування на ринку нових товарів багато в чому залежить від всебічного дослідження вимог ринку. Досліджувана інформація стосується попиту на товари і послуги різних рівнів, вже наявних і потенційно можливих конкурентів, а також вимог, що висуваються споживачами. Збір такої інформації потребує значних витрат часу і коштів. Це змушує підприємства націлюватися на окремі частини ринку, які являють собою сегменти груп споживачів з приблизно загальними вимогами. Пошук таких однорідних сегментів споживачів серед різних варіантів вимог, що висуваються до товару, називається сегментацією ринку, а даний знайдений ділянку ринку - сегментом ринку.

При розумному розподілі ринку на сегменти всі інструменти маркетингу усередині нього можуть бути оптимально скоординовані. Саме тому сегментація ринку вважається дуже важливим аспектом діяльності підприємства.

Методика розрахунку сегментації ринку

При первинній сегментації всього ринку доцільно виділити сегменти товарів споживчого ринку або виробничого призначення. Така класифікація важлива, оскільки підкреслює відмінності в характеристиках продуктів і наслідки для маркетолога.

Для подальшого поділу ринку на сегменти можна скористатися різними критеріями залежно від наступних факторів:

• географічного положення споживачів (регіон, країна);

• типу споживача (величина підприємства, інтенсивність споживання, галузь, місце у виробничому процесі);

• типу процесу, для якого купується продукція (адміністративна діяльність, рух товару, виробничий процес);

• купівельного попиту (клієнт / потенційний клієнт, зв'язок з постачальником, частота і величина закупівель);

На ринках збуту товарів широкого вжитку використовують інші критерії. Класичними є наступні показники:

• соціально-економічні (утворення, доходи);

• демографічні (вік, стать, склад сім'ї);

• географічні

Проте слід враховувати, що всіх споживачів на ринку не так-то легко розділити по категоріях. Поведінка споживача останнім часом стає все більш диференційованим, виникають різні «стилі життя» всередині суспільства.

Для формування сегментації ринку використовуються елементи таксономічного аналізу - побудова діаграм Чекановського. Вихідним кроком, предопределяющим правильність кінцевих результатів, є оформлення матриці спостережень.

Ознаки, включені в матрицю, можуть бути неоднорідні, оскільки описують різні властивості об'єктів. Крім того, розрізняються одиниці їх вимірювання. Тому слід виконати попереднє перетворення, яке полягає в стандартизації ознак.

Таблиця 1. Невпорядкована діаграма Чекановського

У наведеній невпорядкованою діаграмі черговість запису одиниць цілком випадкова. На це вказує виразний розкид символів, що визначають різницю між досліджуваними одиницями: найменше чисельне відстань - C; найбільшу відстань, тобто пари одиниць, найбільш різняться між собою, - Для їх лінійного впорядкування слід провести перегрупування знаків C і. Перегрупування повинна виконуватися таким чином, щоб зазначені знаки виявилися якомога ближче до головної діагоналі діаграми. З цією метою рядки і стовпці таблиці переставляються до тих пір, поки не вийде упорядкована діаграма.

Пошук сегментів ринку для програми установки захищених мережевих з'єднань за допомогою протоколу ISAKMP

Вибуховий характер розвитку комп'ютерних технологій і різко зросла кількість дій скоєних за допомогою глобальної мережі Internet (розвиток електронної торгівлі, надання компаніями через мережу ряду послуг для своїх клієнтів і т.д.) призвело до різкого збільшення обсягів інформації, що передається по мережі. Також зазнав зміни і якісний склад переданої інформації - зросла частка конфіденційної інформації. Разом з тим виникла необхідність аутентифікації іншого боку при всіх перерахованих вище діях. Все це призвело до збільшення ринку програмних продуктів призначених для захисту інформації в мережі. Представлена ​​програма сама по собі не виробляє безпосередньо захист переданої інформації. Завданням програми є автентифікація іншого боку і підготовка інформації, необхідної для безпосереднього захисту переданої інформації.

Виділимо споживачів програми:

1. Системи авторизації доступу, тобто система, якої потрібно провести ідентифікацію та аутентифікацію користувачів. Прикладом може служити сервер компанії, що надає ряд послуг клієнтам компанії. Програма в даному випадку допоможе відсіяти стороннього відвідувача від клієнта.

2. Структура доступу для усередині корпоративної мережі. Програма допоможе зробити обмеження доступу до інформації різних відділів і підрозділів. Наприклад, рядові працівники мають доступ до робочих серверів компанії, але не можуть скористатися інформацією бухгалтерії. Також можливо сегментування інформації всередині окремого підрозділу. Наприклад, відділ маркетингу може скористатися інформацією з бухгалтерії про фінансовий стан компанії, але не має доступу до інформації про заробітну плату співробітників.

3. Віртуальна корпоративна мережа. Зазвичай корпоративна мережа являє собою замкнуту, самодостатню локальну мережу, яка спілкується із зовнішнім світом через комп'ютер фільтруючий проходить через нього інформацію. При цьому жодна секретна інформація з локальної мережі не потрапляє в зовнішню мережу. Недоліком даного підходу є те, що всі учасники цієї мережі повинні були знаходитися у безпосередній близькості один від одного. Програма дозволяє побудувати віртуальну захищену мережу на основі глобальної мережі Internet, шифруючи всю інформацію, передану між учасниками цієї віртуальної мережі. При такому підході можна організовувати мережу навіть між людьми, що знаходяться в різних країнах.

4. Мережа банкоматів. Програма допоможе створити захищені з'єднання з банком для обміну інформації про проведені операції.

5. Міжкорпоративний мережу та мережу для зв'язку з філіями компанії. Програма забезпечує створення захищеного з'єднання для передачі інформації між внутрішніми мережами різних компаній або різних філій однієї компанії (це може бути або локальна мережа, або віртуальна захищена мережа).

Розглянемо параметри програми, які впливають на її функціональність і на спосіб використання програми:

1. Простота налаштувань і обслуговування. Визначає рівень теоретичної підготовки оператора програми.

2. Обсяг налаштувань. Показує, скільки є параметрів для налаштування програми. Більший обсяг налаштувань дозволяє більш гнучко налаштувати програму.

3. Повнота методів аутентифікації. Скільки реалізовано методів аутентифікації і їх функціональна повнота.

4. Повнота відомостей про процес роботи програми. Спосіб збереження цих відомостей, спосіб завдання кількісних і якісних параметрів оброблюваних подій.

5. Повнота реалізації протоколу ISAKMP і сумісність з продуктами третьої сторони.

X = Z =

За формулою (4) розрахуємо матрицю відстаней:

C =

Розбиваємо отриману матрицю на класи, де X - відповідає найменшому чисельному відстані між досліджуваними завданнями (0-1) і отримуємо невпорядковану матрицю Чекановського:

Провівши перегрупування рядків і стовпців (поміняли місцями рядки / стовпчики 3 і 4) отримуємо впорядковану діаграму:

У результаті виконаних обчислень виділився сегмент користувачів програми, що включає в себе користувачів використовують програму для створення систем авторизації доступу, систем розмежування доступу та мереж банкоматів.

У результаті сегментації ринку користувачів програми встановлення захищених мережевих з'єднань за допомогою протоколу ISAKMP був виділений об'єднаний сегмент ринку, що включає в себе використання програми для створення систем авторизації доступу, систем розмежування доступу та мереж банкоматів. Для цього сегмента характерні підвищені вимоги до реалізації методів аутентифікації, системі протоколювання подій і обсягом можливих настройок програми.

Розробка заходів з безпеки роботи з монітором ПК

Обчислювальні комплекси на базі персональних ЕОМ є одним з основних засобів праці розробника на всіх етапах створення програми (проектування, написання, тестування і налагодження).

Розглянувши фактори населеності в даній виробничому середовищі, можна виділити наступні чинники, що роблять шкідливий вплив на організм людини.

• Емісійні:

• Підвищений рівень електромагнітних випромінювань:

• низькочастотного електромагнітного поля (51 ц-400кГц);

• низькоефективного (м'якого) рентгенівського випромінювання (при напрузі на ЕЛТ 15 кВ і вище);

• Підвищений рівень електростатичного поля;

• Ергономічні:

• Чи не ергономічність візуальних параметрів дисплея. Чи не ергономічність конструкції дисплея і клавіатури;

• Чи не ергономічність робочого столу і робочого стільця (крісла);

• Фізичні:

• Підвищена температура, знижена вологість повітря робочої зони;

• Підвищений рівень шуму на робочому місці;

• Недостатня освітленість робочих поверхонь;

• Підвищена яскравість світла в площині екрану дисплея;

• Пряма і відбита блескость;

• Підвищена пульсація освітленості від газорозрядних джерел світла;

• Іонізація повітря;

Психофізіологічні:

• нервово-психічні перевантаження:

• перенапруження зорового аналізатора;

• розумова перенапруга;

• емоційні перевантаження;

• монотонність праці;

• Фізичні перевантаження:

• статичні перевантаження кістково-м'язового апарату;

• локальні динамічні перевантаження м'язів кистей рук;

Джерелом значної частини перерахованих вище шкідливих впливів є монітор персональної ЕОМ.

Електромагнітне випромінювання монітора ЕОМ

Основним джерелом ергономічних проблем, пов'язаних з охороною здоров'я людей, що використовують у своїй роботі персональні комп'ютери, є дисплеї (монітори), особливо дисплеї з електронно-променевими трубками. Вони являють собою джерела найбільш шкідливих випромінювань, що несприятливо впливають на здоров'я операторів. Електромагнітні випромінювання робочої апаратури обумовлені неякісним екрануванням джерел випромінювання в апаратурі. Крім цього, оператор піддається впливу випромінювання від робочої поверхні електронно-променевої трубки.

Додаток загальних положень теорії електродинамічних явищ до конструкції конкретних електричних приладів, зокрема монітора ЕОМ, дозволяє зробити деякі висновки щодо джерел і конфігурації електричних і магнітних полів, випромінюваних цими приладами. Відомо, що електричне поле випромінюється тими частинами електричних установок, в яких використовуються високі напруги, а магнітне поле випромінюється сильними струмами.

У комп'ютері високі напруги використовуються в прискорювальної системі електроннопроменевої трубки (ЕПТ) монітора, а сильні струми течуть в системі управління електронними променями трубки і ланцюгах блоку живлення. Саме ці частини монітора ЕОМ і є основними джерелами електромагнітного випромінювання. Силові лінії електричного поля можна представити починаються в області поблизу заднього кінця ЕЛТ і закінчуються на поверхнях, що знаходяться поблизу монітора, у тому числі і на поверхні тіла користувача ЕОМ, що сидить перед комп'ютером.

Силові лінії магнітного поля утворюють замкнуті конфігурації, що починаються і закінчуються на магнітних кільцях фокусуючої системи ЕЛТ. Безпосередньо перед екраном монітора щільність магнітного потоку досягає величин одиниць мкТл, але швидко зменшується з відстанню від монітора.

Виявлено, що:

1. Електромагнітне поле збуджується на частотах кадрової (60 Гц) і малої (22 кГц) розгорток та їх гармонік;

2. Електричне поле ВДТ близько до електричного поля точкового заряду, а магнітне - до поля магнітного диполя, що знаходяться в геометричному центрі ВДТ. При цьому частоту 60 Гц випромінює система струмів, близька до горизонтального диполя, а 22 кГц - до вертикального;

3. При віддаленні від екрана ВДТ поля швидко спадають. Наприклад, електричне поле спадає в ~ 40 разів при видаленні від екрану на відстань 1,25 м.

Тривала дія на організм людини електромагнітних випромінювань, що перевищують допустимі норми, може призвести до деяких функціональних змін в організмі або навіть пошкоджень тканин і органів. Симптомами є головний біль, порушення сну, підвищена стомлюваність. Функціональні зміни, викликані електромагнітними випромінюваннями, здатні накопичуватися в організмі.

При виборі монітора слід звертати увагу на наявність на щитку (табличка з переліком заводських параметрів виробу) написи про те, що дана модель пройшла тестування на предмет відповідності ТСО 95 (стандарт Шведської конференції профспілок) або MPR II (стандарт Шведського національного комітету із захисту від випромінювань ). Бажано також отримати відомості про наявність Гігієнічного Сертифікату або сертифікатів, виданих іншими організаціями. У той же час, слід мати на увазі, що розкид можливих рівнів електромагнітного випромінювання моніторів однієї і тієї ж моделі може сягати 50%.

Користувачам персональних комп'ютерів, що бажають знизити рівень опромінення змінними магнітними полями, слід розташувати монітори так, щоб відстань до них становило величину, рівну відстані витягнутої руки (з витягнутими пальцями). Оскільки магнітні поля ззаду і з боків більшості моніторів значно сильніше, ніж перед екраном, користувачі повинні розташовувати свої робочі місця на відстані не менш 1.22 м від бічних і задніх стінок інших комп'ютерів. Також для захисту від електромагнітних випромінювань рекомендується використовувати спеціальні захисні екрани. Вони виготовляються з особливого скла і встановлюються між робочою поверхнею монітора і оператором. Такий захист забезпечує затримку від 30 до 90 відсотків усіх шкідливих випромінювань. Такого ж результату можна добитися шляхом усунення джерела випромінювання від оператора. Тим не менш, не рекомендується проводити за екраном дисплея більш 3-х годин на день.

Електроопасность і пожежонебезпека

Монітори ПК живляться від мережі змінного струму напругою 220 В з частотою 50 Гц, що являє саме по собі серйозну небезпеку для життя і здоров'я людини.

Дія електричного струму на живу тканину носить різнобічний характер: термічний вплив, електрична та біологічна дії. Все це веде до електричних травм і електричним ударам, що в свою чергу може призвести до порушення і навіть до повного припинення життєдіяльності організму.

Вихід впливу електричного струму на організм залежить від ряду факторів, в тому числі і від електричного опору тіла, величини і тривалості дії струму, роду і частоти струму. Граничний відчутний струм становить 0,6 ... 1,5 мА для постійного струму.

Безпечний струм, який може протягом тривалого часу проходити через людину, не викликаючи ніяких відчуттів, становить приблизно 50 мкА (для змінного струму з частотою 50 Гц) і 100 мкА (для постійного струму). При збільшенні величини струму до 10 ... 15 мА біль стає ледь стерпної, і судоми м'язів стають настільки значними, що людина не в змозі їх подолати. Таким чином, граничний не відпускають струм складає 10 ... 15 мА для частоти 50 Гц і 50 ... 80 мА для постійного струму. Струм величиною 100 мА (частотою 50 Гц) і 300 мА (постійний струм) і більше викликають припинення діяльності серця через 1-2 с.

Приміщення для роботи з ЕОМ і з її зовнішніми пристроями зазвичай відносять до категорії приміщень з підвищеною небезпекою, тому що є можливість ураження електричним струмом. Найчастіше джерелами поразки є блоки ЕОМ, корпуси пристроїв і приладів у разі виникнення несправності (наприклад, при порушенні захисного заземлення або ізоляції проводів, а також при застосуванні неправильних прийомів включення в мережу і вимикання з мережі вилок електроживлення).

Захистом від дотику до струмоведучих частин електроустановок служить:

ізоляція провідників;

використання захисних кожухів;

використання інструментів з ізолюючими ручками при ремонті обладнання ЕОМ.

Проведемо розрахунок опору ізоляції.

Правила електробезпеки встановлюють норми опору ізоляції та вимоги до її діелектричної міцності. Для електричних машин та апаратів мінімальне значення опору ізоляції визначається за формулою:

[МОм],

де U - напруга, В;

N - потужність установки, кВт.

Звідси випливає, що при напрузі живлення 220 В і потужності монітора 250 Вт опір ізоляції має бути не менше ніж:

.

Дуже важливим організаційним заходом є також проведення обов'язкового і періодично повторюваного інструктажу з електро - і пожежобезпеки всіх осіб, які допускаються до роботи на ЕОМ. При проведенні періодично повторюваних протипожежних інструктажів необхідно обов'язково домагатися, щоб персонал практично вмів користуватися первинними засобами гасіння пожежі та засобами зв'язку

Для гасіння пожежі повинні застосовуватися ручні вогнегасники і переносні установки. Електромережі та електроустановки, які знаходяться під напругою, гасити водою не можна ні в якому разі, тому що через струмінь води може відбутися ураження електричним струмом. Саме тому для гасіння пожежі, яка виникла через несправність електроприладів, застосовують тільки пінні вогнегасники.

Можливість швидкої ліквідації пожежі багато в чому залежить від своєчасного оповіщення про пожежу. Зазвичай на підприємствах електронної промисловості дуже поширеним засобом оповіщення є телефонний зв'язок.

Вимоги до висвітлення при роботі з монітором ПК

Збереження зору людини, стан його центральної нервової системи і безпека на виробництві значною мірою залежать від умов освітлення.

Виробниче освітлення повинно відповідати таким вимогам:

1. Освітленість повинна відповідати характеру праці, що визначається об'єктом відмінності, фоном, контрастом об'єкта з фоном.

2. Необхідно забезпечити достатньо рівномірний розподіл яскравості на робочій поверхні, а також в межах навколишнього простору. Світле фарбування стелі, стін і виробничого устаткування сприяє створенню рівномірного розподілу яскравості в полі зору.

3. На робочій поверхні повинні бути відсутні різкі тіні. Особливо шкідливі рухомі тіні, які можуть призвести до травм. Тіні необхідно пом'якшувати, застосовуючи, наприклад, світильники зі светорассеивающими молочними стеклами. На вікнах необхідно передбачати сонцезахисні пристрої (наприклад, жалюзі).

4. У полі зору повинна бути відсутнім блескость. Блескость - підвищена яскравість світяться поверхонь, що викликає порушення зорових функцій (засліпленість), тобто погіршення видимості об'єктів. Блескость знижують зменшенням яскравості джерела світла або вибором раціональних кутів світильника.

5. Величина освітленості повинна бути постійною в часі. Коливання освітленості, викликані різким зміною напруги в мережі, призводять до значного стомлення. Пульсація освітленості пов'язана також з особливостями роботи газорозрядної лампи. Зниження коефіцієнта пульсації з 55 до 5% (при трифазному включенні) призводить до підвищення продуктивності праці на 15%.

6. Слід вибирати оптимальну спрямованість світлового потоку. Найбільша видимість досягається при падінні світла під кутом 60 градусів до його нормалі, а найгірша при нулі градусів.

7. Слід вибирати необхідний склад спектру освітлення. Це істотно при роботах, де потрібна правильна передача кольору.

8. Всі елементи освітлювальних установок повинні бути досить довговічними, електро - і вибухобезпечними.

Забезпечення цієї умови досягається застосуванням занулення або заземлення, обмеженням напруги для харчування місцевих або переносних світильників до 42 вольт і нижче.

Аналізуючи умови роботи програміста, отримуємо такі вимоги до виробничого освітлення:

- Найменша допустима освітленість від загального освітлення становить 300 лк;

- При роботі за комп'ютером бажано, щоб освітленість робочого місця не перевищувала 2 / 3 нормальної освітленості приміщення;

- Екран дисплея не повинен бути орієнтований у бік джерел світла (вікон, настільних ламп тощо);

при розміщенні робочого місця поряд з вікном кут між екраном дисплея і площиною вікна повинен становити не менше 90 градусів (для виключення відблисків), прилеглу частину вікна бажано зашторити;

- Не слід розташовувати дисплей безпосередньо під джерелом освітлення або впритул з ним;

- Стіна позаду дисплея повинна бути висвітлена приблизно так само, як і його екран;

- Яскравість для блискучих поверхонь більше 0.2 кв. м не повинна перевищувати 500 кд / кв. м;

- Показник осліпленості не повинен перевищувати 40 одиниць;

- Коефіцієнт пульсацій 10 - 20%.

Специфіка роботи за ЕОМ, полягає в тому, що працювати доводиться з так званим самосвітних об'єктом.

Світіння з боку екрану, а також часта зміна заставок на екрані при великій тривалості трудової діяльності може негативно впливати на зір. Такий режим роботи стомлює зорові органи. Тому розробнику програмного забезпечення слід враховувати цей фактор при проектуванні програмного забезпечення та його налагодження за комп'ютером.

У цьому розділі розглянуті питання безпечної роботи з монітором ПК і дані практичні рекомендації зі створення оптимальних умов праці при роботі з монітором ПК.

Були розглянуті природа електромагнітних випромінювань, їх вплив на організм людини і способи захисту від них.

Розглянуто питання електробезпеки і пожежної безпеки при роботі з монітором. Проведено розрахунок необхідного опору ізоляції.

Наведено вимоги до висвітлення у виробничому приміщенні в цілому і при роботі з монітором ПК.

Висновок

У представленій роботі - «Програма установки захищених мережевих з'єднань з використанням протоколу ISAKMP», - були вирішені наступні завдання:

• Досліджено структуру протоколу ISAKMP і вразливість його мережевим атакам

• Розроблено та проаналізовано загальна структура захисту інформації при передачі по мережі.

• Визначено місце розроблюваної програми в цій системі і визначені інтерфейси до неї.

• Розроблено і написана програма, що реалізує протокол ISAKM

• Проведені необхідні налагодження та тестування програми, методи проведення тестування були наведені у відповідному розділі роботи.

У процесі дослідження була розглянута структура протоколу ISAKMP, розглянуті склад і порядок посилки пакетів, і порядок проведення необхідних розрахунків. Також розглянуті основні типи мережевих атак, і те, як протокол протистоїть їм.

При описі процесу розробки програми були представлена ​​багатонитковою структура програми і обгрунтована необхідність і переваги використання саме цієї структури. Були докладно пояснені процес створення нитки і передача інформації між нитками.

Література

1. Єдина система програмної документації ГОСТ 19.001-77, 19.002-80, 19.003-80, 19.101-77, 19.102-77, 19.505-79.

2. Зубов М.М., П'янзіна А.Я. Методичні вказівки до дипломного проектування зі спеціальності «Програмне забезпечення обчислювальної техніки і автоматизованих систем» / За ред. В.Ф. Шаньгіна; МІЕТ. М., 1990

3. «Security Architecture for the Internet Protocol» RFC2401 листопада 1998

4. «Internet Security Association and Key Management Protocol (ISAKMP)» RFC2408 листопада 1998

5. «The Internet Key Exchange (IKE)» RFC2409 листопада 1998

6. «The Internet IP Security Domain of Interpretation for ISAKMP» RFC2407 листопада 1998

7. Bruce Schneier «Applied Cryptography Second Edition: protocols, algorithms, and source code in C» 1996

8. «Advanced Programming in the UNIX Environment» W. Richard Stevens 1994

9. «UNIX System V Network Programming» Stephen A. Rago 1994

10. «Programming with Threads» Steve Kleiman, Devang Shah, Bart Smaalders 1996